Skip to main content
A Journey runs a graph of nodes once per user when you trigger it. The canvas and the API build the same object, so pick the one that matches who owns the flow. A journey a product manager will keep tuning belongs in the canvas. A journey generated per customer, or checked into your repo, belongs in the API. A journey is not a broadcast. It runs per user, from an event or an API call, rather than going out to a group at a moment you choose. If you want one message to a list right now, use a .

Build in the canvas

1

Create the Journey

Open , select New Journey, and name it. Choose the API Invoke trigger so your code starts each run.
The New Journey dialog with a name field and four trigger options
2

Add a send node

Drop a send node on the canvas, pick a channel, and select + Create to build its content inline. Each send node owns one Template scoped to this Journey.
3

Add a delay

Drag a delay node between the trigger and the send. Set it to wait a day. Journeys also offer branch, fetch data, throttle, batch, and digest nodes.
4

Publish

Select Publish to lock the draft as a version. New runs use it. Runs already in flight finish on the version they started with.Copy the Journey ID from the editor.

Build with the API

1

Create the Journey

takes a name and the node list. The list starts with a trigger and ends with an exit, and node ids are left out because the API assigns them. It returns the Journey ID.
2

Add a scoped Template

creates the content a send node uses. These Templates belong to the Journey, separate from your workspace Templates.
3

Wire the graph

takes the full node list, in the same body shape as the create call:
  • the trigger
  • a send node referencing the Template ID
  • any delay or branch nodes
4

Publish

snapshots the draft as the active version.

Invoke a run

Either path ends the same way. Publishing makes the journey live, and a run starts when your app invokes it by ID or alias. covers the call in every language. It also covers the Idempotency-Key that stops a retry starting a second run, and how to inspect or cancel a run by its runId.

Limits & behavior

Editing a send node’s content after publishing changes nothing on its own. The edit saves as a new template draft. The journey keeps sending the version it was published with, and no error marks the difference, so publish the journey again to make the edit live. Runs already in flight finish on the version they started with. A publish does not migrate them, so a change to a multi-day flow reaches only the runs that begin after it.