Skip to main content
Build it with your AI agent. We highly recommend it: set up your agent with the , then ask it to build this.
A journey sends a series of messages from one event, like a signup. In this example, you’ll build a three-day kickoff series with the API for Acme Fit, a workout app. New members get one workout email a day for their first three days.
1

Get your API key

Copy a key from and export it. Every example reads it from COURIER_API_KEY.
2

Create the journey

takes a name and a node list. Every journey starts with a trigger and ends with an exit. The API Invoke trigger lets your code start each run.
The response returns the journey’s id. Every call below uses it.
3

Write the three emails

once per email. The meta element’s title is the subject, and action renders a button. scope: "strict" means every variable names its source: data. for what you send with the run, profile. for the user.
Each call returns the template’s id, which you need in the next step. The Node.js and Python tabs create all three emails. In the other tabs, run the same call twice more with these names and elements:
Elements for the other two emails
A journey run sends each template’s published version, which is why each one is created with state: "PUBLISHED". Publishing the journey doesn’t publish its templates.
4

Wire the nodes

sets the full node list. Nodes run in array order, so this list is the whole series. Each send node points at one of your templates by its id in message.template. Delays take an ISO 8601 duration. Both delays here are PT1M (one minute) so you can watch the whole series land in about two minutes.
Before real signups, replace the nodes again with P1D (one day) for both delays and publish. Runs use the published version, so a journey left on PT1M sends all three emails in two minutes.
5

Publish

makes this version the one new runs use. Runs already in flight finish on the version they started with.
6

Start it from your signup code

starts one run for one user. Call it from your signup code right after you create the account, using the journey ID you saved in step 2. To try it now with a Test key, replace sarah@example.com with the address you signed up with, so the series lands in your inbox. Test includes a built-in email provider for that address. Any other address, or a Production key, needs .
The run starts in the background, so the call returns before anything sends. The Day 1 email goes out within seconds, and the response carries a runId:
7

Watch the run

returns each node the run reached, in node order rather than the order they ran. Every step shares the run’s created_at, so the examples sort by updated_at, the time each step last changed state. The first delay reads WAITING until its minute is up, and each send step carries the message_id it produced.
The journey’s Logs tab in draws the same run on the canvas. See .

​
FAQ

Check that you published the journey and created each template with state: "PUBLISHED". Then look up the step’s message_id in . Delivering to real addresses needs an .
The canvas and the API build the same object, so the journey opens in like any other. To build one in the canvas from the start, follow .
Add "cancelation_token": "kickoff-{{recipient}}" to the create or replace body. {{recipient}} resolves to the user_id you invoke with, so Sarah’s run carries kickoff-user_123. Cancel that token when she unsubscribes or deletes her account, and her remaining emails don’t send. See .
Add a branch node after the first delay that checks whether the user already finished Day 1, and end the run on that path. walks through it.
Each invoke starts a new run, so a retry sends the Day 1 email twice. Send an Idempotency-Key header, such as signup-user_123, and a repeated key returns the first run instead. See .