Skip to main content
An assertion is a condition that a step’s response must satisfy for the journey to consider that step successful. Assertions are how a journey proves behavior — they transform a sequence of API calls into a verifiable test of intended outcomes.

​
When to use it

Add assertions whenever a step’s response needs to confirm something specific:
  • The HTTP status code matches what you expect (200, 201, 422).
  • A response body field has a particular value or shape.
  • A header is present or absent.
  • A derived value falls within an expected range.
Without assertions, a journey is just a sequence of requests. With them, it’s a contract: “this workflow must produce these results.”

​
Key concepts

Assertions live at the step level. Each step carries its own set of assertions. A step passes when all its assertions pass; if any assertion fails, the step fails and the journey records the failure. Assertions define acceptance criteria. In Build mode, the journey canvas surfaces acceptance criteria alongside steps. These criteria are what the Coverage view uses to determine whether the journey is proving what it should. Template assertions vs. journey assertions. A request template can include default assertions (e.g., “status is 200”). When you add that template as a step, you inherit those defaults and can extend or override them in the journey. Assertion failures are not crashes. A failed assertion records which condition didn’t hold, what the actual value was, and what was expected. The run continues to capture as much evidence as possible (unless configured to halt on failure). Assertions appear in run output and evidence. After a run, you can see exactly which assertions passed, which failed, and what values they evaluated against — useful for debugging and for runbook evidence collection.

​
How it works

  1. In Build mode, select a step and open its assertions panel.
  2. Add assertions by specifying what to check (status code, body field, header) and the expected value or condition.
  3. When the journey runs, each step’s response is evaluated against its assertions.
  4. Passed assertions contribute to the run’s success. Failed assertions are recorded with actual vs. expected values.
Common assertion types:
TypeExample
Status codestatus == 201
Body field equalsbody.status == "pending"
Body field existsbody.order_id is present
Header presentresponse.headers["X-Request-Id"] exists
Body containsbody.items has length > 0

​
Examples

A step that creates an order should assert: 
assertions:
  - type: status
    equals: 201
  - type: body
    path: "$.order.status"
    equals: "pending"
  - type: body
    path: "$.order.id"
    exists: true
If the API returns 200 instead of 201, or the body contains "status": "failed", the assertion fails and the run records the discrepancy.