Multi-Step API Monitoring: How to Catch Failures Simple Pings Miss
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 wrote a full tutorial on monitoring API authentication flows that covers advanced patterns like OAuth and refresh tokens. 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.
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.
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. This is usually the response body (JSON), but you can also extract from response headers.
- Path. The location of the value you want. For JSON responses, this is a JSONPath expression like
$.data.tokenor$.result.items[0].id. For headers, this is the header name. - Variable name. The name you give this value so you can reference it in later steps. Use descriptive names like
auth_tokenorcart_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(or201for 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
tokenfield. 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 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.
For example, if your site uses a React-based login form that talks to a REST API, set up a multi-step API monitor to test the API authentication flow, and a browser login monitor to test the frontend login experience. If the API is fine but the React form has a rendering bug, the browser monitor catches it. If the form renders fine but the API returns invalid tokens, the API monitor catches it.
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 North America. Paid plans unlock all 5 global regions. No credit card required.
Start monitoring your API flows for free and find out what single-endpoint checks are missing.