Flow templates

Writing a flow graph from nothing is the slowest and most error-prone way to build one. The template list is the shortcut: a catalogue of ready-made journeys (an abandoned-checkout reminder, a welcome, a winback and others), each scored for this particular project against the events it actually receives, and each carrying a complete graph with the trigger event and its source already chosen.

The intended path is to take the payload of the closest template, change only what you need, and create the flow from it.

The dashboard shows the same list as its template gallery, with the same recommendations; how customers use it is described in Flows → Templates.

The endpoint takes the PROJECT_AUTOMATION_READ scope and sits in the medium rate-limit class.

Query parameters

The response

{
  "entities": [
    {
      "key": "abandoned-checkout",
      "title": "Abandoned checkout",
      "description": "Reminds shoppers who started a checkout and did not buy within 30 minutes. Stops as soon as they order.",
      "categories": ["ecommerce", "checkout_abandoned"],
      "icon": "shopping-cart",
      "recommended": true,
      "integrations": [
        { "integration": "shopify", "name": "Shopify", "connected": true }
      ],
      "channels": ["sms", "rcs"],
      "channel": "sms",
      "relevance": "received",
      "trigger": {
        "eventType": "ecommerce_checkout_init",
        "datasourceId": "66c3a1b2e5a6b7c8d9e0f1a2",
        "candidates": ["ecommerce_checkout_init"],
        "lastSeenAt": "2026-09-25T08:41:12+00:00"
      },
      "score": 60,
      "scoring": [
        { "signal": "relevance", "delta": 40, "text": "My Shop sent 412 ecommerce_checkout_init events in the last 30 days" },
        { "signal": "business", "delta": 20, "text": "Suited to ecommerce businesses" }
      ],
      "used": false,
      "payload": { "trigger": { "stepClass": "TRIGGER_CONTACT_EVENT", "eventType": "ecommerce_checkout_init", "...": "..." } }
    }
  ],
  "window": { "days": 30 }
}

window.days is the window the event counts behind relevance and scoring cover. It follows the plan: 30 days on free plans, 180 on paid ones, the same bound the event volumes probe applies.

Relevance

Relevance answers the question that decides whether a flow will ever fire: does the event it triggers on actually arrive in this project?

Relevance is data first. The events a project really receives outweigh the business type it declared, so a project that sells online while describing itself otherwise still sees the ecommerce journeys, as long as its orders arrive.

When a template can trigger on more than one event (a review request can follow a delivery or, failing that, a shipment), the first candidate the project receives is the one the payload uses, and a scoring sentence says so. A trigger filter in the graph follows the event it was rewritten to.

Scoring and order

score is the sum of the delta of every scoring entry. The signals include the trigger's relevance (a received event weighs most), extra sources that also send it, how well the template suits the project's business type, whether the trigger is the project's own sales conversion event, and whether a complementary or overlapping flow already exists. Each entry says in plain words what it measured, so the list can be shown to a person, or read by a model, as the reason a template is on offer.

Templates are ordered with used ones last, then by score. Treat the weights as the platform's judgement, not a contract: read scoring rather than recomputing it.

SMS or RCS with SMS fallback

Templates are authored as SMS. channel=rcs rebuilds every send in the payload as a plain-text RCS message with the same SMS, unchanged, as its fallback for contacts RCS cannot reach. The consent policy is the same on both levels. There is no RCS-only mode.

• rcs is accepted only when the template's channels lists it, which means the project has an active RCS sender; otherwise the request is a 400.
• The mode is never chosen for you. RCS messages are billed as RCS, so offer it as an option to the person who will publish the flow rather than switching to it on their behalf.

Message language

The messages in payload are written in the project's language: Spanish for a Spanish project, English otherwise. lang only translates title and description.

When the organization's plan allows multi-language messages, every send in the payload also carries the other language as a translation, in the option's localizations. At send time each contact receives the translation matching their language, and anyone else receives the default text. See Translations.

What the payload leaves to you

A template payload validates as soon as one thing is added: the sender of each send. It is never set, on the message or on its translations, because which sender speaks for the brand is the customer's choice. Created without one, the flow is saved with valid: false and an error on each send, and it can be completed in the dashboard. See The send.

Everything else is already filled in the way the platform recommends:

• The trigger listens to the event's preferred source, and the exits to the same source.
• The audience is restricted to contacts with a mobile phone, so nobody enters a journey that can never send.
• Every marketing send waits in a smart delay that avoids illegal hours, and every send declares its consent policy.
• A contact is never inside two runs of the same flow at once, and journeys that should happen once (a welcome) or not too often (a checkout reminder) carry their own re-entry limits.

Creating a flow from a template

1. 1

   List the templates

   Call GET /flow/templates and pick the item to use: typically a recommended one, or the one the user asked for by name.

2. 2

   Set the senders

   Add the id of a sender from this project to each send in payload. Change anything else the user asked for, and nothing more.

3. 3

   Create the flow

   Send the payload as draft and the item's key as template, so the flow records where it came from and the template is marked used.

curl -X POST "$BASE/flow" \
  -H "Authorization: Bearer $INSTASENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Abandoned checkout",
    "template": "abandoned-checkout",
    "draft": { "trigger": { "stepClass": "TRIGGER_CONTACT_EVENT", "eventType": "ecommerce_checkout_init" } }
  }'

The draft above is shortened: send the whole payload. The response and its errors are in Creating and editing drafts. An unknown template key is a 400.

What would an integration unlock

integration=<key> answers "which journeys would connecting this integration make possible?". It keeps only the templates that integration can feed and scores them as if it were connected:

• If the project has connected it, the templates score on its real data.
• If it has not, the integration counts as a source that has sent nothing yet, so its templates come back available with no trigger.datasourceId, unless another source already sends the event.

An unknown integration, or one that cannot trigger flows, is a 400. Take the keys from the integrations of the items.

Errors

What's next