Skip to main content
Template assertions are checks attached directly to a request template. Any step that uses the template inherits those assertions automatically — you don’t have to redefine them in every journey that calls the same endpoint.

​
When to use it

Use template assertions for checks that should always be true for this endpoint regardless of context: the response status code should be 200, the response body should always include an id field, a specific header must be present. These are structural expectations about the endpoint itself, not about a particular journey’s behavior. If an assertion is specific to one journey’s flow — for example, “the returned balance should be greater than the amount passed in the previous step” — put it on the step instead.

​
Key concepts

  • Template-level vs. step-level assertions — template assertions are inherited by every step that uses the template. Step assertions are local to that step in that journey. Both run during execution.
  • Inheritance — when a step uses a template, its assertions combine with any step-level assertions you’ve added. Template assertions run first.
  • Shared enforcement — a template assertion enforces a consistent baseline across all journeys. If the assertion fails anywhere, you know the endpoint itself is behaving unexpectedly, not just one workflow.

​
How it works

Template assertions follow the same assertion syntax as step-level assertions. You can assert on:
  • Status code — e.g., response status must equal 200 or be in the 2xx range.
  • Response headers — e.g., Content-Type must contain application/json.
  • Response body fields — e.g., body.id must be present, body.status must equal active.
  • Response time — e.g., response must complete within 2000 ms.
When a step runs, Reqflo evaluates template assertions against the response first, then any step-level assertions. Both sets of results appear in the run output for that step.
Template assertions are a good place for contract-level checks — the kind of thing you’d write in an API integration test. Step assertions handle behavior that depends on the journey’s specific values and flow.

​
Examples

Status code and content-type assertions 
assertions:
  - type: status
    equals: 200
  - type: header
    name: Content-Type
    contains: application/json
Body field presence and value constraints 
assertions:
  - type: body
    path: id
    exists: true
  - type: body
    path: created_at
    exists: true
  - type: body
    path: status
    oneOf:
      - active
      - pending
Response time 
assertions:
  - type: response_time
    lessThan: 2000
How template and step assertions combine A template for POST /v2/payments might assert: 
# Template assertions — run for every step that uses this template
assertions:
  - type: status
    equals: 201
  - type: body
    path: payment.id
    exists: true
A step in a specific journey then adds: 
# Step assertions — run only for this step in this journey
assertions:
  - type: body
    path: payment.amount
    equals: "{{inputs.amount}}"
  - type: body
    path: payment.status
    equals: pending
Both run when the step executes. The template assertions verify the endpoint contract; the step assertions verify the journey-specific behavior.

Step assertions

Assertions added directly to a step for journey-specific checks.

HTTP request templates

The full shape of an HTTP request template.

Assertion reference

Complete reference for all assertion types and operators.

Run mode

How assertion results appear in run output.