Skip to main content
An assertion answers the question: did this step do what it was supposed to do? After an HTTP request step executes, its assertions run against the response. If an assertion fails, the step is marked as failed, the failure is surfaced in run output, and (depending on run configuration) the journey may stop or continue to collect further evidence.

​
When to use it

Add assertions to a step any time the response outcome matters — which is most of the time. Specifically:
  • To verify a success status code (200, 201, 204, etc.)
  • To check that a response body field has the expected value
  • To confirm a required field is present (or absent)
  • To validate a response against a schema or type
  • To set a time-based expectation (response time under a threshold)
If a step has no assertions, it executes and captures outputs, but there’s nothing to say whether it actually succeeded in any meaningful sense. For coverage to be meaningful, assertions need to be attached.

​
Key concepts

Assertion target. Each assertion points at something in the response: a status code, a body field path (e.g., body.user.id), a header, or a response time measurement. Operator. The assertion compares the target to an expected value using an operator: equals, not equals, contains, not contains, exists, not exists, greater than, less than, matches (regex), and others. See Assertion reference for the full list. Expected value. The value to compare against. Like step field values, the expected value can be hard-coded or derived from a value source (a variable, step output, run input, etc.) — so you can assert dynamic values, not just static ones. Pass/fail. All assertions on a step must pass for the step to be considered passed. A single failing assertion marks the step as failed. Soft assertions. Some assertion configurations can be set as non-blocking — they report a failure without stopping the run. This is useful when you want to collect evidence across all steps even if one check fails.

​
How it works

Open a step in Build mode and navigate to its assertions section. Add one or more assertions:
  1. Choose what to assert against (status, a body field path, a header, response time).
  2. Choose the operator.
  3. Set the expected value — either a literal or a dynamic value source.
During a run, assertions execute immediately after the step’s response is received. Results appear in run output per step: which assertions passed, which failed, and the actual vs. expected values for each. In debug mode, you can pause after a step and inspect assertion results before continuing the run.

​
Examples

Check the response status: 
assertions:
  - target: status
    operator: equals
    expected: 201
Check a body field value: 
assertions:
  - target: body.order.status
    operator: equals
    expected: pending
Check a field exists: 
assertions:
  - target: body.order.id
    operator: exists
Compare against a step output (dynamic expected value): 
assertions:
  - target: body.customer_id
    operator: equals
    expected: { source: run-input, key: customer_id }
Check response time: 
assertions:
  - target: response_time_ms
    operator: less_than
    expected: 2000

HTTP request steps

The step type assertions are attached to.

Assertion reference

Full list of assertion operators and targets.

Coverage

How assertions connect to journey-level acceptance criteria.

Step outputs

Use step outputs as dynamic expected values in assertions.