PulseTrace
Start free
All monitor types
Advanced / Synthetic

Multi-Step API Test monitoring

A chained, synthetic workflow: several requests in sequence, passing values between steps, with per-step assertions and scripts.

Every Multi-Step API Test monitor runs on the same spine as the rest of PulseTrace — probed from each region you pick, scored on every check, and streamed into one timeline where incidents open on their own, anomalies surface without a threshold to guess, and reports are generated for you. Point it at a target, choose an interval, and it's watched.

What each check verifies

  • Ordered request steps with variables carried between them
  • Per-step response, header and JSON assertions
  • Pre-request and post-response scripts (pulse.* API); optional cleanup steps

The panel on the right is the real create-monitor screen — it fills itself in with a Multi-Step API Test example, exactly what you'd type.

Start monitoring free Read the docs

When to use it

For the flows that make you money — sign in then load the account, create then read then delete, search then add to basket. When a single request can't prove the system works, a journey of requests with values passed between steps can.

What an alert looks like

Checkout journey FAILED at step 3 of 4 (POST /orders) — expected 201, got 500; steps 1–2 passed in 412 ms.

Plan availability

Team and above.

Compare plans →

Related

HTTP(S)gRPCWebSocketMulti-step API checksAPI monitoringIncident management

Questions about Multi-Step API Test monitoring

How do I pass a token from step 1 to step 2?
Extract it with a JSON path or header name into a variable, then reference the variable in any later step's URL, headers or body.
Does a journey count as one monitor?
Yes — one journey is one monitor against your plan limit, regardless of step count.
← gRPC