Skip to main content
See also: Journeys concept and configuration for what this API powers, when to call it, and how it is configured.
Journeys list view in the Studio module

The Journeys editor.

GET /api/v1/journeys

List all journeys with offset-based pagination.

Query Parameters

Response


POST /api/v1/journeys

Create a new journey.

Request Body

Definition validation

The definition graph is structurally validated on create and update. A payload that fails any of these checks is rejected with 422 VALIDATION_ERROR (details.fields.definition lists every problem):
  • nodes and edges must be arrays (of objects)
  • every node needs a non-empty string id, and node ids must be unique
  • every edge’s source and target must reference an existing node id
  • the graph must be acyclic (the runtime engine has no loop guard, so cycles are rejected at save time)
Node type values are not restricted — the engine executes entry_trigger, wait, condition_split, nba_decision, channel_action, ab_split, webhook_wait, and exit (the Studio editor exposes the first six; ab_split and webhook_wait are API-authored).

Example

Response: 201 Created

GET /api/v1/journeys/

Get journey details.

PUT /api/v1/journeys/

Update a journey. All fields are optional. Response: 200 OK

DELETE /api/v1/journeys/

Delete a journey. Requires admin role. Response: 204 No Content

POST /api/v1/journeys//enroll

Enroll one or more customers into an active journey. The journey must be in active status. Duplicate enrollments are silently skipped (not errors).

Request Body

Provide either customerId or customerIds, not both.

Response — 201 Created

Error Codes


POST /api/v1/journeys//test

Test Mode — a real-engine dry run. Runs one (real or synthetic) customer through the whole journey and returns a step-by-step trace. Condition splits use the production operator logic and NBA Decision steps call the real decision engine (draft flows previewed), so the offers returned are the ones that customer would actually receive. To keep it safe and instant: waits are fast-forwarded, Channel Action sends are simulated (nothing is delivered), and nothing is persisted (no enrollment, no queue jobs). See Testing a journey. Requires the admin or editor role.

Request Body

Response

Node behavior in Test Mode


POST /api/v1/journeys/callback/

Resumes an enrollment that is paused on a webhook_wait step. When the engine reaches a webhook_wait node it generates a one-time UUID token, an HMAC-SHA256 signature, and an expiry (default 48h, timeoutHours config), stores them on the enrollment, and sets the enrollment status to waiting. An external system calls this endpoint to advance the journey. This endpoint is public — no session or API key required. The signed URL is the credential: the route verifies the HMAC signature (keyed by WEBHOOK_SIGNING_SECRET) and expiry, and the token is one-time use. It is rate-limited per IP (10/min) and per token (5/min).
The optional JSON body is passed to the engine as customer context — a condition_split immediately after the webhook_wait can branch on it.

Response — 200 OK

Error Codes


GET /api/v1/journeys//analytics

Get journey funnel analytics including enrollment counts, completion rates, and per-step metrics.

Response


Roles

See also: Journeys