Skip to main content
An HTTP request step represents a single API call in your journey. You pick a request template, configure where each part of the request gets its value, and optionally capture outputs and attach assertions. String enough of these together and you’ve got an end-to-end API workflow.

​
When to use it

Every journey that makes API calls is built from HTTP request steps. You’d add one any time you need to:
  • Call an endpoint as part of a multi-step workflow
  • Set up state (create a resource) before testing something downstream
  • Validate a request/response pair against acceptance criteria
  • Pass a value from one response into the next request

​
Key concepts

Request template. Each step is backed by a request template from your library. The template defines the HTTP method, path, headers, body shape, and recommended parameter configuration. The step inherits that definition and lets you configure how each value is supplied at run time. Value sources. A request has many parts — URL, path params, query params, headers, body fields, auth. Each field can be independently wired to a value source. See Step values for the full list. Step outputs. After a request runs, you can capture values from the response (status code, body fields, headers) and make them available to later steps. See Step outputs. Assertions. You can attach acceptance criteria to a step. Assertions run after the response arrives and determine whether the step passed or failed. See Assertions.

​
How it works

1

Add a step

In Build mode, add a step to the journey canvas and select a request template from your library. The template populates the step with the request definition.
2

Configure values

Open the step’s value configuration. For each field that needs a value (path params, headers, body, auth), choose a source: run input, variable, step output, hard-coded, environment, secret reference, or “me” value.
3

Capture outputs (optional)

If a later step needs data from this response — an ID, a token, a computed field — define a step output to extract it. Name the output so you can reference it downstream.
4

Attach assertions (optional)

Add assertions to check the response: status code, body fields, headers, response time. Assertion failures mark the step as failed in run output.
5

Run the journey

When the journey runs, each HTTP request step executes in order. Run output shows the request sent, the response received, assertion results, and any captured outputs.

​
Examples

A simple two-step journey — create a resource, then fetch it: 
steps:
  - name: Create order
    template: create-order
    values:
      body.customer_id: { source: run-input, key: customer_id }
      body.amount: { source: variable, key: order_amount }
    outputs:
      - name: order_id
        from: body.id

  - name: Get order
    template: get-order
    values:
      path.order_id: { source: step-output, step: create-order, output: order_id }
    assertions:
      - field: status
        equals: 200
      - field: body.status
        equals: pending
Passing a secret as an auth header: 
values:
  headers.Authorization: { source: secret-reference, name: api-key-header }
The secret’s value is never stored in the journey; the Cloud Runner (or your local environment) resolves it at run time.

Request template library

Browse and manage the request templates your steps pull from.

Step values

All the ways a step field can be wired to a value source.

Step outputs

Capture and reference response values in later steps.

Assertions

Attach acceptance criteria to a step.