Transaction monitors (multi-step API)

A Transaction monitor runs an ordered sequence of HTTP steps as one check — the synthetic-flow monitoring you'd otherwise buy from a dedicated API-testing product. Each step can extract variables from its response (a login token, an order id) and later steps can use them in their URL, headers or body. The check passes only when every step passes; execution stops at the first failure, and the failing step's response snapshot is attached to any incident it opens.

Typical use: prove that your API's whole login flow works — not just that the login endpoint returns 200.

Plan availability: Transaction monitors are available on the Business plan and up.

Concepts

• Steps — up to 10 per monitor, run strictly in order. Each step is a full request: name, method, URL, headers and (for POST/PUT/PATCH) a body.
• Assertions — every step takes the same assertion rows as an API monitor: status, latency, JSONPath, response header, body contains, with the same operators. A step with no assertions passes on any 2xx/3xx status.
• Variable extraction — after a step's assertions pass, its extract rules pull values out of the response, from the JSON body (by JSONPath, e.g. $.token) or from a response header (by header name). Variable names are lowercase identifiers: letters, digits and underscores, starting with a letter (max 32 chars).
• Monitor variables — optional values defined once on the monitor (e.g. a test account's password). They are stored encrypted, never re-displayed after saving, and always redacted in results and logs.
• Substitution — write {{name}} in any later step's URL, header value or body and it is replaced at run time. The form refuses a {{reference}} that isn't a monitor variable or extracted by an earlier step (a step can't reference its own extracts — extraction happens after the response).

Example: login → fetch orders → assert

Monitor variable: password = the test account's password (stored encrypted).

Step 1 — Log in

• POST https://api.example.com/auth/login
• Header: Content-Type: application/json
• Body: {"email": "monitor@example.com", "password": "{{password}}"}
• Assertions: Status code equals 200
• Extract: token from JSON body at $.token

Step 2 — Fetch orders

• GET https://api.example.com/orders
• Header: Authorization: Bearer {{token}}
• Assertions:
  • Status code equals 200
  • JSON path $.items not equals [] (the list must not be empty)

If step 1's credentials break, the transaction fails at step 1 with the failed assertion, step 2 never runs, and the incident carries step 1's response snapshot (status, headers, body head) for diagnosis.

Results and diagnostics

The monitor page shows a per-step waterfall from the latest run: each step's name, HTTP status, duration and — on failure — which assertion broke. The recorded latency is the total transaction time across all executed steps. When a failing check confirms a DOWN and opens an incident, the failing step's response snapshot is stored with the incident (see Incident forensics).

Limits and safety

• Maximum 10 steps per transaction; steps after the first failure are skipped.
• The whole transaction shares the standard 30-second check budget, and each step is capped at 10 seconds — one slow hop can't consume the run.
• Every step URL (and every redirect hop) is re-validated by the SSRF guard on every run — extracted variables can change the host between steps, so each step is vetted independently. Private, link-local and metadata addresses are always refused.
• Secrets hygiene: monitor variables are encrypted at rest; check results store each step's URL template (never the substituted URL), no request headers or bodies, and extracted values by name only.

Related

• API monitors and assertions — the single-request version and the full assertion reference.
• Incident forensics — what gets captured when a check confirms a DOWN.