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

Multistep checks are available on paid plans only. A check can have up to 10 steps, and each run is billed per step per location.

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:

• A step name.
• An HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS).
• A URL.
• Headers and a request body, behind the Headers / Body toggle.
• 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, click Add extract rule, enter a Variable name, and choose where the value comes from:

• Body (JSON): enter a JSON path such as user.id or data.token. Use dots for nested fields and a number for an array position, for example items.0.id.
• Header: enter the header name, for example Location or Set-Cookie.
• Status code.

The value is stored in the variable you named. A rule runs only when its step passed.

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. A placeholder whose variable was never set is replaced with empty text and no error is raised, so check the variable name if a later step behaves oddly.

Assertions and Pass/Fail

Each step has its own assertions on status code, response time or body. The steps combine into one aggregate result:

• If every step passes, the check passes.
• If a step fails (the request errors or an assertion fails), the chain stops at that step and the whole check is marked failed, and 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: each step's name, status code and duration, which assertions passed or failed, and the values it extracted. A Duration over time chart sits below the steps. 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.