Multistep API Checks

What a Multistep API Check Is

A Multistep API Check runs an ordered sequence of HTTP requests as a single check, passing data from earlier responses into later requests. Instead of monitoring one endpoint in isolation, you can reproduce a real workflow — for example, log in, capture an authentication token, then call an authenticated endpoint and assert on its response.

This is the right check type whenever a single request can't prove that your API actually works end to end:

• Authenticate, extract a token, then call a protected endpoint with it.
• Create a resource, capture its id, then read or delete it.
• Chain a search request into a detail request.
• Walk a short user journey across several endpoints in order.

Create a Multistep API Check

1. Open the New API Check page.
2. Choose the Multistep API check type.
3. Give the check a friendly name (used in alerts and reports).
4. Add your steps in the order they should run.

For the shared settings — frequency, locations, alert channels, activate/mute — see How to Create a New API Check; a Multistep check uses the same options.

Add Ordered Steps

Each step is its own HTTP request with:

• An HTTP method (GET, POST, PUT, PATCH, DELETE).
• A URL.
• Headers.
• A request body.
• One or more assertions.

Steps run in order, top to bottom. The first step runs, then the second, and so on. You can reorder steps as your workflow changes.

Pass Data Between Steps

The power of a Multistep check is moving data from one response into the next request.

Extract a value from a step's response

On a step, add an extract rule that pulls a value from that step's:

• Response body (for example, a JSON field such as the access token).
• Response header (for example, a Location or Set-Cookie value).
• Response status.

Store the extracted value in a named variable.

Reference the variable in a later step

Use a {{variable}} placeholder anywhere in a later step's URL, headers, or body. At run time LoadFocus substitutes the captured value.

For example, capture a token from step 1 into a variable named token, then send it in step 2:

Authorization: Bearer {{token}}

Variables are resolved in step order, so a step can only use values that earlier steps have already extracted.

Assertions and Pass/Fail

Each step has its own assertions (status code, body, headers, response time), exactly like a single API check. The steps combine into one aggregate result:

• If every step passes, the check passes.
• If a step fails, the chain stops at that step and the whole check is marked failed — later steps do not run.

This fail-fast behaviour mirrors a real workflow: if login fails, there's no point calling the authenticated endpoint.

Per-Step Results in the Report

The check report shows per-step results so you can see exactly where a sequence broke: the method and URL of each step, its response time, which assertions passed or failed, and where the chain stopped. This makes it easy to pinpoint whether a failure was in authentication, in the downstream call, or in an assertion.

You can find all your checks on the API Monitors page.