Guide

Multi-Step API Monitoring: How to Catch Failures Simple Pings Miss

April 9, 202612 min read

TL;DR: Multi-step API monitoring chains 3 to 10 HTTP requests into a single check, passing tokens and IDs between steps so the monitor fails the way a real user's session would. Use it for login, payment, and checkout flows where a single 200 OK on one endpoint hides the real outage. Velprove includes multi-step API monitors on the free plan (3 steps), Starter (5 steps), and Pro (10 steps), with commercial use allowed on every tier and 5 global regions.

Most monitoring tools check one page or one endpoint at a time. They send a request, get a response, confirm the status code is 200, and move on. If the server responds, everything looks fine.

But your users do not visit one page and leave. They log in, load their account, process a payment, place an order. Each of those actions involves multiple requests that depend on each other. The login returns a token. That token loads the dashboard. The dashboard fetches their data. If any link in that chain breaks, the feature breaks. A single-endpoint monitor will never catch it.

Multi-step API monitoring solves this by chaining requests together, passing data from one step to the next, exactly the way your application does. If the chain breaks at any point, you get an alert before your users start filing support tickets.

This guide is for SaaS founders and teams running custom backends with API endpoints. If your site uses a standard login form (WordPress, Shopify, WHMCS), Velprove's free browser login monitors are a better fit. They open a real browser, fill in your credentials, and verify login works. No API knowledge required.

The Problem with Monitoring Endpoints in Isolation

When you monitor each endpoint separately, you are testing whether it responds. You are not testing whether it works as part of a larger flow. These are fundamentally different things.

Consider a simple example. Your /api/login endpoint returns 200 OK when you send it valid credentials. Your single-endpoint monitor confirms this every five minutes. But the token it returns could be invalid. Your session storage could be full, causing new logins to silently fail. A recent update could break token verification on the services your app connects to.

In all three cases, your login endpoint responds with a 200. Your monitor stays green. And every single user who tries to log in gets an error on the very next page they visit. We covered this blind spot in detail in our guide on why uptime monitors miss real outages. The core issue is the same: checking that a server responds tells you almost nothing about whether your application actually works.

The only way to catch these failures before your users do is to test the full sequence. Send credentials, receive a token, use that token to access a protected resource. If any step fails, the monitor fails. That is what multi-step API monitoring does.

How Multi-Step API Monitoring Works

Multi-step API monitoring is a technique that chains multiple API requests into a single monitor, passing data between steps and validating each response along the way. If any step in the API chain fails, the entire monitor fails and triggers an alert.

A multi-step API monitor chains multiple HTTP requests into a single check. Each step can extract data from the previous step's response and use it in headers, request bodies, or URLs for subsequent steps. Assertions run on every step. If any assertion fails, the entire monitor fails and you receive an alert.

Think of it as replaying a real user workflow against your API on a schedule. Instead of asking "does this endpoint respond?" you are asking "does this entire flow work end-to-end?"

In Velprove, you create a multi-step API monitor by adding steps in order. For each step, you configure the HTTP method, URL, headers, and request body. You set assertions on the response (status code, body content, response time). And you extract values from the response to use in later steps. The free plan supports up to 3 steps per monitor. Starter supports 5 steps, and Pro supports 10.

Let us walk through three real-world flows to see how this works in practice.

Example 1: Authentication Flow

Authentication is the most common multi-step flow and the one most likely to break silently. If you have ever seen a login page that loads perfectly but refuses every valid credential, you know what this looks like from the user side. We cover advanced patterns like OAuth and refresh tokens later in this guide. Here is the basic setup.

Step 1: Send login credentials

Create a POST request to your login endpoint. For most APIs, this is something like /api/auth/login or /api/v1/sessions. Set the request body to include your test account's email and password in JSON format. Add an assertion that the response status is 200.

Use a dedicated test account for monitoring. Do not use a real customer account. You do not want automated checks to trigger rate limits or security lockouts on an account someone actually uses.

Step 2: Extract the authentication token

Configure the monitor to extract a value from the Step 1 response. For a typical JWT-based API, you extract the access_token or token field from the JSON response body. In Velprove, you specify the JSON path (like $.data.access_token) and give the extracted value a name (like auth_token). This value is now available in all subsequent steps.

Step 3: Access a protected endpoint

Create a GET request to a protected endpoint, something like /api/me or /api/user/profile. In the request headers, set Authorization to Bearer {{auth_token}}. The monitor replaces the variable with the actual token extracted in Step 2. Assert that the response returns 200and that the response body contains expected data, like the test account's email address.

Now your monitor validates the complete authentication flow every time it runs. If the login endpoint breaks, you know. If the token it returns is invalid, you know. If the protected endpoint rejects valid tokens, you know. All from a single monitor.

Advanced Authentication Patterns

The basic 3-step monitor above covers a standard email-and-password login. Real applications use a wider mix of auth patterns. Here are the four most common variations and how to monitor each one. Most of them fit inside the free plan's 3-step limit. Refresh-token testing is the one case where you need 5 steps.

OAuth 2.0 client credentials

For backend-to-backend integrations and API gateways, the OAuth 2.0 client credentials grant is the standard. Your service exchanges a client_id and client_secret for an access token, then uses that token to call protected APIs.

Set up a 2-step monitor. Step 1 POSTs the credentials to the token endpoint (often /oauth/token or /connect/token), asserts 200, and extracts the access_token. Step 2 GETs a protected API endpoint with Authorization: Bearer {{access_token}}, asserts 200, and checks for a known field in the response. Two steps cover the full backend-to-backend round trip.

JWT with refresh tokens

If your application issues short-lived access tokens with a refresh token alongside, the failure mode you most want to catch is a broken refresh endpoint. Users get logged out unexpectedly, but the login endpoint and protected endpoints both look healthy in isolation.

Test the full refresh cycle with a 5-step monitor. The pattern is the same regardless of stack:

Step 1. POST credentials to /api/auth/login. Assert 200. Extract access_token as at1 and refresh_token as rt.
Step 2. GET a protected endpoint like /api/me with Authorization: Bearer {{at1}}. Assert 200 to confirm the first access token works.
Step 3. POST to /api/auth/refresh with the refresh token in the request body. Assert 200. Extract the new access token as at2.
Step 4. GET the same protected endpoint with Authorization: Bearer {{at2}}. Assert 200. This is the step that catches a broken refresh path. If the refresh endpoint returns a malformed token, the new request fails here.
Step 5. Optionally assert that the response body contains the expected user identifier (an email or a user ID). Catches the case where the refresh path silently swaps the user context.

This pattern requires 5 steps, which means the Starter plan or higher. The free plan caps at 3 steps and is the right tier for the basic login monitor and the OAuth client credentials pattern above.

Session cookies and CSRF tokens

Traditional session-based authentication uses cookies rather than tokens. The login response sets a session cookie, and every subsequent request reuses it. This is the model WordPress, WHMCS, and most framework-default auth setups still use.

Don't force a multi-step API monitor here. API monitors don't share a cookie jar between steps, and CSRF protection adds another round-trip just to fetch the token. The right tool for session-based login is Velprove's browser login monitor. It uses a real browser to handle cookies and CSRF natively, and verifies the post-login state the same way a real user would. Free plan includes one. Setup walkthroughs are in our WordPress login monitoring guide and our WHMCS portal monitoring guide.

Monitoring across multiple auth providers

If your app supports multiple login methods (email and password plus Google OAuth plus SAML, for example), set up one multi-step monitor per provider. A failure in one tells you nothing about the others. SAML can break while OAuth keeps working. Three or four providers fits inside the free plan's 10-monitor allotment alongside your other critical checks.

Example 2: Payment Flow

Payment flows are where silent failures cost real money. Your checkout page loads, the form accepts credit card details, but nothing actually processes. Or your webhook receiver stopped acknowledging events, so subscriptions are not being activated after successful payments. We have a detailed guide on monitoring Stripe API health for the third-party side of this. Here is how to monitor your own payment processing flow.

Step 1: Create a checkout session

Send a POST request to your checkout session endpoint (for example, /api/checkout/create-session). Include the necessary parameters: a test product ID, a quantity, and the test customer's identifier. Assert that the response returns 200 and contains a session ID. Extract the session_id from the response.

Step 2: Verify session status

Send a GET request to your session status endpoint, like /api/checkout/sessions/{{session_id}}. Assert that the response returns 200 and that the session status field is pending or created. This confirms your system is creating valid checkout sessions that are ready for payment processing.

Step 3: Check subscription state

For subscription-based products, add a step that checks the test customer's subscription endpoint, like /api/subscriptions/current. Use the test customer's authentication token (you can extract it the same way as in the authentication example above). Assert that the response returns the expected plan and status. This validates that your subscription management system is responding correctly and returning accurate data.

This three-step monitor covers the creation side of your payment flow. If your checkout session endpoint stops generating valid sessions, you find out immediately. If the session data is malformed, you catch it. If your subscription service stops responding, you know before a customer tries to upgrade and fails.

The same chained pattern works in reverse for inbound webhooks. See our walkthrough on monitoring inbound Stripe webhooks, which uses a 3-step chain to verify a synthetic event was received, signature-validated, and applied as the right side effect.

Example 3: API Workflow Monitoring for E-Commerce Checkout

For e-commerce sites, the checkout flow is the most critical path in your entire application. Every step has to work: adding items to a cart, applying discounts, calculating totals, and submitting the order. A failure anywhere in this chain means lost sales. Here is how to monitor it.

Step 1: Add an item to the cart

Send a POST request to your cart endpoint, like /api/cart/items. Include a test product ID and a quantity of 1 in the request body. Assert that the response is 200 or 201 and that the response body contains the product in the cart. Extract the cart_id from the response for use in the next steps.

Step 2: Apply a coupon code

Send a POST request to your coupon endpoint, like /api/cart/{{cart_id}}/coupon. Include a permanently valid test coupon code in the request body. Assert that the response is 200 and that the discount amount is greater than zero. This validates that your pricing engine, coupon validation, and cart calculation are all working together.

Why test coupons specifically? Because coupon logic often depends on external services or complex business rules that fail independently of the rest of your checkout. Time-based discounts, usage limits, product-specific rules. Any of these can break without affecting the cart endpoint itself.

Step 3: Submit the order

Send a POST request to your order validation endpoint, like /api/orders/validate. Include the cart_id, test shipping details, and test payment method. Assert that the response is 200 and that the response body contains an order summary with the correct total (reflecting the coupon discount from Step 2).

Use a validation endpoint rather than an actual order submission endpoint for monitoring. You do not want your monitor creating real orders every five minutes. If your application does not have a separate validation endpoint, consider adding one. It is useful for both monitoring and frontend validation.

With this three-step monitor, you are testing the full checkout path from product selection through discount application to order validation. If your inventory service goes down, the cart step fails. If your pricing engine breaks, the coupon step catches it. If your order processing system has issues, the final step flags it.

Configuring Response Extraction in Velprove

The key to multi-step monitoring is passing data between steps. Without this, each step is just an independent check and you lose the ability to test real workflows. Here is how response extraction works in Velprove.

After you configure a step's request and assertions, you can add one or more extraction rules. Each extraction rule has three parts:

Source. Where to extract from. Extraction works on the response body, which must be valid JSON.
Path. The location of the value you want. This is a JSONPath expression like $.data.token or $.result.items[0].id.
Variable name. The name you give this value so you can reference it in later steps. Use descriptive names like auth_token or cart_id.

Once extracted, you reference variables in any subsequent step using double curly braces: {{variable_name}}. You can use them in URLs, headers, and request bodies. The monitor replaces the variable with the actual extracted value before sending the request.

If extraction fails (because the expected field is missing from the response, or the JSON path does not match), the monitor fails immediately. This is by design. A missing token or session ID is a real failure that should trigger an alert.

Assertions That Actually Catch Problems

Setting up the steps and extraction is half the job. The other half is writing assertions that catch real problems, not just confirming the server did not crash.

For each step, you should assert on at least two things:

Status code. The obvious one. Assert that the response is 200 (or 201 for creation endpoints). But do not stop here.
Response body content. Assert that the response contains a specific field or value. For a login step, assert that the response contains a token field. For a cart step, assert that the response contains the product name. For an order step, assert that the total is greater than zero.

You can also assert on response time. If your login endpoint normally responds in 200 milliseconds and suddenly takes 3 seconds, something is wrong even if the response is technically correct. Setting a response time threshold catches performance degradation before it becomes an outage.

For a deeper walkthrough of response validation strategies, see our guide on monitoring REST API health endpoints. The same principles apply to each individual step in a multi-step monitor.

How to Alert on Authentication and Payment API Failures

A slow homepage is annoying. A broken login or checkout means no one can use your product or pay you. Auth and payment monitors deserve a different alerting strategy than your marketing site. Treat them as critical-severity from day one.

Use shorter intervals on critical flows. Velprove's free plan checks every 5 minutes, which is fine for marketing pages. Authentication and payment flows benefit from the 1-minute interval on Starter or the 30-second interval on Pro. Faster intervals turn a 5-minute outage into a 1-minute outage in your alert window. All 5 global monitoring regions are available on every plan.
Route to higher-urgency channels. Email is the default. On paid plans, route auth and payment failures to Slack, Discord, Teams, or webhooks so they hit the right room or rotation. PagerDuty is available on the Pro plan for teams running on-call.
Use separate test credentials with low privilege. Create a dedicated test account for monitoring. Never use a real customer account or admin credentials. The safest approach is a monitoring-only account with the minimum permissions needed to walk the flow. Avoids security lockouts, rate limits, and the operational mess of a leaked monitoring credential.
One monitor per auth provider. Separate monitors give you clean attribution in alerts. If your Google OAuth path breaks, the alert names the Google monitor specifically rather than a generic "authentication failed" that could mean any of three providers.

How Many Steps Do You Actually Need?

The free plan includes 3 steps per multi-step monitor. That is enough for the three examples in this guide: each one uses exactly 3 steps. For most applications, 3 steps covers the critical path of any single workflow.

You might need more steps if your flows involve additional stages. Some real-world examples that benefit from 5 or more steps:

Authentication with refresh token testing (login, extract token, access resource, refresh token, access resource again with new token).
Multi-stage checkout with address validation, tax calculation, shipping rate lookup, and order confirmation.
API workflows that create a resource, modify it, verify the modification, and then clean up the test data.
Onboarding flows that create an account, verify the email, set preferences, and load the initial dashboard.

Starter ($19/month) supports 5 steps. Pro ($49/month) supports 10, which covers even the most complex multi-stage workflows. Start with the free plan and upgrade when your monitoring needs grow.

When to Use Multi-Step vs. Browser Login Monitors

Velprove offers both multi-step API monitors and browser login monitors. They solve different problems, and the best monitoring setup usually includes both.

Use multi-step API monitors when you are testing backend workflows. Login authentication, payment processing, order creation, subscription management. These are the behind-the-scenes operations where you need to validate that data flows correctly between each step.

Use browser login monitors when you are testing the user-facing experience. A real browser opens your login page, fills in credentials, clicks the submit button, and verifies the login succeeds. This catches JavaScript errors, broken form rendering, CSS issues, and redirect problems that API monitors cannot see.

Run both side by side on critical flows. The API monitor catches backend regressions, the browser monitor catches frontend regressions, and together they cover what either alone would miss.

Getting Started

You can set up your first multi-step API monitor in about five minutes. Here is the quickest path to meaningful coverage:

Identify your most critical user flow. For most applications, this is authentication.
Create a dedicated test account with known credentials.
Set up a 3-step monitor: login, extract token, access protected endpoint.
Add assertions on status codes and response body content for every step.
Set your check interval. The free plan runs every 5 minutes, which is a solid starting point. Starter runs every minute, and Pro runs every 30 seconds.

Once your authentication monitor is running, add monitors for your payment flow and any other critical paths. Each multi-step monitor runs independently, so you get clear alerts that tell you exactly which flow is broken.

Velprove's free plan includes 10 monitors with multi-step support (up to 3 steps each) and 1 browser login monitor. Free plan monitors from all 5 global regions. No credit card required.

If you are still cross-shopping monitoring tools, see our decision framework comparing 15 uptime monitors across 5 use cases.

Start monitoring your API flows for free and find out what single-endpoint checks are missing.

More Guides

Frequently Asked Questions

What is multi-step API monitoring?

Multi-step API monitoring chains multiple HTTP requests into one check. Each step can extract data from the previous response and use it in subsequent steps. If any step or assertion fails, the whole monitor fails. This validates real workflows like login and checkout, not just whether a single endpoint responds.

How do you monitor an OAuth client credentials flow?

Set up a 2-step monitor. Step 1 POSTs client_id and client_secret to the OAuth token endpoint, asserts 200, and extracts the access_token. Step 2 calls a protected API with Authorization: Bearer plus the token and asserts 200. Two steps fit inside Velprove's free 3-step limit and are the right shape for backend-to-backend integrations.

Can you monitor JWT refresh tokens?

Yes. Use a 5-step monitor. Step 1 logs in and extracts access_token and refresh_token. Step 2 hits a protected endpoint with the access token. Step 3 posts the refresh token to the refresh endpoint and extracts a new access_token. Step 4 hits the protected endpoint with the new token. Step 5 optionally asserts the user identifier. Requires Starter or higher (free caps at 3 steps).

How do you monitor session-based authentication?

Use a browser login monitor instead of an API monitor. API monitors don't maintain a shared cookie jar across steps, and CSRF tokens add brittle extra exchanges. The browser monitor drives a real browser and handles cookies and CSRF natively. Standard approach for WordPress, WHMCS, and most session-based applications.

How often should authentication monitors run?

Auth and payment flows are critical-severity. The free plan checks every 5 minutes, which is fine for non-critical paths. Starter runs every 1 minute and Pro runs every 30 seconds. Pair short intervals with high-urgency channels like Slack, Discord, or PagerDuty on paid plans so on-call rotations get notified within a minute of a real failure.

Is multi-step API monitoring free?

Yes. Velprove's free plan includes multi-step API monitors with up to 3 steps per monitor and 10 monitors total, with commercial use explicitly allowed. Starter unlocks 5-step monitors and Pro unlocks 10-step monitors. All 5 global monitoring regions are available on every plan, including the free tier.