Skip to main content
A step is one unit of work inside a journey. Steps run in sequence, and each step can read values from previous steps, produce outputs for later steps, and carry assertions that must pass for the run to succeed. The journey canvas in Build mode is organized around steps.

​
When to use it

You add steps whenever you need to model an action in the workflow. A journey that authenticates, creates a resource, and verifies the resource has three steps. Each step is distinct: it has its own request, its own value configuration, and its own assertions.

​
Key concepts

HTTP request steps are the only step type currently available. An HTTP request step is built from a request template that defines the request shape (method, path, headers, body). You configure how the step gets its values and what assertions it must satisfy. Step values — each step can receive values from many sources: run inputs, declared variables, derived values, previous step outputs, hard-coded values, environment values, secret references, or “me” values. See Values and variables. Step outputs — a step can expose parts of its response as named outputs that downstream steps consume. A common pattern: step 1 captures a token from a response, step 2 uses that token in its authorization header. Assertions — each step can carry assertions (status code, body field checks, header checks, and so on) that determine whether that step passed or failed. See Assertions. Planned step types — the following step types are not yet available but are on the roadmap:
The step types below are planned and not yet available.
  • Connectors — integrate with external systems.
  • Sub-journeys — embed one journey inside another.
  • Scripts — run custom logic between steps.
  • Set variables — assign or compute a variable mid-journey.
  • Notes — attach documentation or context to a position in the journey.
  • Manual checkpoints — require a human to confirm success before proceeding (used in Runbooks).

​
How it works

  1. In Build mode, you add a step to the journey canvas by selecting a template from the request template library.
  2. You configure the step’s value sources — which fields come from run inputs, which from previous step outputs, which are hard-coded, and so on.
  3. You add assertions to define what “success” looks like for that step.
  4. When the journey runs, steps execute in order. Each step’s response is evaluated against its assertions and its outputs are made available to subsequent steps.

​
Examples

A three-step journey that creates and confirms an order: 
Step 1: POST /auth/token
  - Values: username → run input, password → secret reference
  - Outputs: access_token from response body

Step 2: POST /orders
  - Values: Authorization header → step 1 output (access_token)
  - Outputs: order_id from response body
  - Assertions: status == 201

Step 3: GET /orders/{order_id}
  - Values: order_id → step 2 output
  - Assertions: status == 200, body.status == "pending"