API Flow Monitoring — Multi-Step API Checks with Variable Passing

What is API flow monitoring?

API flow monitoring — also called multi-step monitoring or synthetic transaction monitoring — checks a sequence of API calls that depend on one another, rather than testing a single endpoint in isolation. Real user actions are rarely a single request: logging in returns a token, that token authorizes an order, and the order ID is used to query status. Each call depends on the output of the previous one.

Traditional uptime monitoring tells you whether one URL responds. But your login endpoint can return 200 while the end-to-end flow is broken — a downstream service is down, a token format changed, or a database is unreachable. Flow monitoring catches these because it exercises the whole path the way a real client would.

Why single-endpoint checks aren't enough

• Dependencies hide failures — step 1 can succeed while step 3 fails on a downstream dependency you'd never see from a single check.
• Auth flows break silently — a token endpoint returning 200 doesn't mean the token still authorizes the next call.
• Data contracts drift — a renamed JSON field breaks the next step even though every individual endpoint is “healthy.”
• Async jobs need polling — “submit job → poll until done” can't be verified by one request.
• Critical paths deserve real coverage — checkout, signup, and payment flows are exactly the paths you can't afford to have silently broken.

How chained monitors work

Sequential steps

A chain is an ordered list of HTTP steps. Each step has its own method, URL, headers, body, expected status, and optional keyword check. Steps run top to bottom; if any step fails its checks, the chain stops and is marked down.

Variable passing between steps

Reference an earlier response with {{stepN.path}}. For example Authorization: Bearer {{step1.data.token}} injects the token step 1 returned. You can pull from the JSON body, response headers ({{step1.headers.x-id}}), the status code ({{step1.status}}), and array indices ({{step1.data.items.0.id}}).

Loop polling

Turn any step into a loop: it re-fires every N milliseconds until a success keyword appears (e.g. "status":"done"), a fail keyword appears, or a max-iteration limit is reached. Perfect for async APIs that return a job ID and require polling for completion.

Field-level encryption

Encrypt specific request body fields with AES and decrypt response content, with keys managed locally and never uploaded. Lets you monitor internal APIs that require encrypted payloads.

Step-by-step testing & export

Test up to any step and inspect the exact request sent (after variable substitution and encryption) and the full response, with a per-check pass/fail breakdown. Export any step's request as a curl command or Python snippet to reproduce it on another machine.

How to set up a multi-step monitor

1. Create a chain monitor — in the dashboard, click “Add Monitor” and choose the Chain type (Pro plan and above).
2. Add step 1 — e.g. a POST to /login that returns an auth token in its JSON response.
3. Reference it in step 2 — use {{step1.data.token}} in the URL, headers, or body of the next step.
4. Add a loop step if needed — for async jobs, enable looping with a success keyword so the step polls until the job completes.
5. Test each step — run up to a step and verify the substituted request and the response before saving.
6. Save — Status Shuttle runs the whole chain on each check. If any step fails it marks the chain down, auto-pauses it, and sends a single alert so you fix the root cause without alert spam.

Frequently Asked Questions

What is API flow monitoring?

API flow monitoring (also called multi-step or synthetic transaction monitoring) checks a sequence of API calls that depend on each other, rather than a single endpoint in isolation. A login endpoint can be 'up' while the overall login → order → query flow is broken. Status Shuttle's chained monitors run each step in order, pass values between them, and mark the whole flow down if any step fails.

How do I pass a value from one step to the next?

Use the {{stepN.path}} syntax. For example, if step 1 returns a JSON body {"data":{"token":"abc"}}, you can put Authorization: Bearer {{step1.data.token}} in step 2's headers. You can reference body fields, response headers ({{step1.headers.x-request-id}}), the status code ({{step1.status}}), and array indices ({{step1.data.items.0.id}}).

Can it poll an endpoint until a job finishes?

Yes. Any step can be a loop step: it re-fires every N milliseconds until a success keyword appears in the response (e.g. "status":"done"), a fail keyword appears, or a max-iteration limit is hit. This is ideal for async APIs that return a job ID and require polling for completion.

Is multi-step monitoring free?

Chained monitors are a Pro plan feature ($5/year) and above. The free plan covers HTTP(S) and keyword monitoring for single endpoints. Pro adds chained monitors, Ping, TCP, SSL, faster intervals, and more.

Can I see exactly what each step sent and received?

Yes. When testing, each step shows the real request as sent (URL, method, headers, and body after variable substitution and encryption) and the full response (status, headers, body) with a pass/fail breakdown for each check. You can also copy any step's request as a curl command or Python snippet to reproduce it elsewhere.

Can request fields be encrypted?

Yes. Chained monitors support field-level AES encryption of request body fields and decryption of response content, with keys managed locally and never uploaded. This lets you monitor internal APIs that require encrypted traffic.