Skip to main content

​
Stream Triggers

A stream trigger starts a flow when a message is published to a subject you nominate. The message body becomes the flow’s trigger data. They are listed under Advanced Features in the Add Node panel, alongside the other trigger types.
Delivery is best-effort. A message starts the flow only if it arrives while the platform is listening. There is no retry, no queue of failed messages, and no way to re-run a message that was missed or that started a flow which then errored. Messages already sitting in a stream do not start the flow either — only new ones do.Use a stream trigger for signals where a missed message is acceptable — cache warming, notifications, opportunistic processing. Where every message must be accounted for, prefer a Webhook trigger or the HTTP Request trigger, where the sender sees a response and can retry.

​
The two trigger types

Both listen to a single subject. The stream dropdown on Stream Message is a convenience for picking a subject that already exists; the trigger does not read stored messages from that stream, and the two types behave identically once saved.
The trigger panel also shows a read-only Full URL row. That is the general URL for running a flow directly, not the address messages are published to. It plays no part in a stream trigger.

​
Setting up

  1. Add a Stream Message or Message Subject trigger to your flow.
  2. Give it a Trigger Name.
  3. For Stream Message, choose the stream and then the subject. For Message Subject, type the subject.
  4. Save the flow.
On Stream Message, the editor will let you save with a stream chosen but no subject; the platform then rejects it with a trigger source subject is required for this type. Always pick a subject.
Streams themselves are created and browsed in the app’s left rail under Resources → Storage → Streams, where each stream’s own settings — retention, maximum age, message limits, duplicate window — are set.

​
Reading the message

The published message body is the trigger data, with nothing wrapped around it. If you publish:
then in the flow’s steps:
Or $.trigger for the whole body.
There is no message metadata to read. $.trigger.message, and paths such as .subject, .timestamp, .id and .sequence beneath it, do not exist — nothing is delivered but the body you published. If the flow needs the subject or a timestamp, put them in the message body yourself.
Request headers are available at $.env.headers.

​
Publishing messages

To let an outside system publish to the subject, create a gateway mapping of type Stream whose resource is that subject, then post to the gateway’s URL with the API key in the x-api-key header:
Two things follow from how the mapping works:
  • A mapping publishes to one fixed subject — the one set as its resource. Nothing in the request body chooses a subject. To feed several subjects, create a mapping for each.
  • The whole request body is the message. It is not unwrapped and no field is treated as routing, so a {"subject": …, "data": …} envelope would arrive as $.trigger.subject and $.trigger.data.* rather than routing anywhere.

​
Naming subjects

Subjects are dotted, most general segment first — orders.created, orders.shipped, inventory.low-stock. A consistent hierarchy lets one flow take a narrow subject while another takes a broader one. Wildcards are available only on the free-text Message Subject trigger: * matches one segment, > matches the rest of the subject. The number of * segments has to line up with the subject being matched, and the platform rejects the trigger at save time when it does not. On Stream Message, the subject comes from a dropdown, so patterns cannot be typed there.

​
Draft and published flows

A stream trigger binds to the version of the flow that was open when you created it. Create it while editing and it is bound to the draft. Publishing the flow does not re-point it, so the published flow will not receive messages. After publishing, open the published flow and create the trigger there.
The product has two actions: Save, which keeps your edits on the draft, and Publish, which makes them live.
What runs after the trigger is decided by each step’s outcome, not by the arrows in the editor. A Condition step’s outcome names the step IDs to run next — one, several (they start at the same time), or the reserved RESOLVE_SUCCESS / RESOLVE_ERROR to end the run. A line drawn between two steps that no outcome names is decoration, and an outcome naming a step that is not in the flow fails the run with next step not found.

​
Troubleshooting

Check the subject matches exactly, including every segment. Then check which version of the flow the trigger is on — a trigger created while editing belongs to the draft, not the published flow.
Expected. Only messages published after the trigger exists start the flow; stored messages are never read.
Delivery is best-effort, so a message published while the platform was not listening is gone. If that is not acceptable for the data, move the integration to a webhook or HTTP trigger, where the sender learns whether the call succeeded.
A Stream Message trigger needs both a stream and a subject. A Message Subject trigger with wildcards needs its segment count to match.
Open the run in Monitoring. The message is not re-delivered, so fix the step and re-run the flow manually with the same data.

​
Next Steps

Webhook Trigger

Start a flow from an HTTP callback

HTTP Request Trigger

Call a flow directly and get a response

Triggers Overview

Every way a flow can start

Variable Mapping

Reading trigger data in later steps