All features
Synthetic API

Multi-step API monitoring: login, call, verify — as one journey

Real user flows are sequences: authenticate, create, read back, clean up. A Multi-Step API monitor chains requests, passes values from one step to the next, and fails the journey at the exact step that broke.

Each step is a full HTTP request with its own assertions. Extract a token or an id from a response and use it in the next step's URL, headers or body. The journey runs on schedule from your regions like any other monitor, and every execution keeps each step's request, response and timing.

When a step fails you get the step number, the assertion that failed and the captured response — not just 'journey failed' — so the fix is obvious.

  • Variable passing between steps from JSON paths or headers.
  • Per-step assertions and timing, with the full exchange captured.
  • Credentials from the vault so secrets never sit in the monitor.
  • Executions view to replay any run step by step.
incidents · live
checkout-api unreachable
downtime · 3 regions · opened 2m ago
Critical
TLS chain changed on cdn.acme.io
intelligence · acknowledged
Warning
db-replica latency recovered
anomaly · resolved automatically
Resolved

How it works

  1. 1Create a Multi-Step API monitor and add steps: method, URL, headers, body, assertions.
  2. 2Extract variables from responses (JSON path or header) for later steps.
  3. 3Run on demand to verify, then schedule; failures open incidents at the failing step.

Plan availability

Team and above.

Compare plans →

Questions about multi-step api checks

How many steps can a journey have?
As many as the flow needs; a journey counts as one monitor against your plan's limit regardless of step count.
Can I run it manually before scheduling?
Yes — on-demand executions run the whole journey now and show each step's request and response.