API Monitoring Done Right: JSON Assertions, GraphQL Checks, and Multi-Step Flows

Your API returns a 200 status code. Your monitoring tool marks it as healthy. But the response body is empty, a required field is null, the pagination is broken, and your mobile app is crashing for every user. Status codes are not enough. Modern API monitoring requires validating what the API actually returns — the structure, the values, and the behavior across multi-step workflows. Here is how to do it right.

The Problem With Status-Code Monitoring

Most monitoring tools check whether your API responds with a 200 and call it a day. This catches complete outages — server down, DNS failure, network unreachable — but misses the failures that actually hurt your users:

• Schema changes — a deployment renames a field from user_name to username and every API consumer that depends on the old field name breaks silently.
• Empty responses — your database connection pool is exhausted, so the API returns {"data": []} instead of actual results. Status code: 200.
• Null values — a required field starts returning null because of a migration issue. Downstream services that parse this field throw exceptions.
• Performance degradation — the API responds, but it takes 8 seconds instead of the usual 200ms. For your users, that is functionally equivalent to being down.
• Authentication failures — your auth service returns 200 with {"authenticated": false} instead of the expected 401, so your monitoring never catches it.

Every one of these scenarios passes a basic HTTP check. Every one of them degrades your users' experience.

JSON API Monitoring With Assertions

Monitorion's JSON API monitor lets you define assertion rules that validate the response body, not just the status code. You make an HTTP request to your API endpoint and then check whether the JSON response meets your expectations.

Assertion rules support a range of operators:

• Field existence — verify that a key exists in the response. Catch schema changes before they break consumers.
• Value equality — check that a field equals a specific value. Confirm that $.status equals "active" or that $.version matches your expected API version.
• Numeric comparisons — verify that $.data.length is greater than zero, or that $.response_time is less than a threshold.
• String matching — check that a field contains or matches a specific pattern. Useful for verifying that responses include expected data.
• Type validation — ensure fields return the expected type (string, number, array, object). Catch type coercion bugs before your frontend does.

You can combine multiple assertions on a single monitor. For a user API endpoint, you might assert that the response contains a $.data array, that the array has at least one element, and that each element contains an id field. If any assertion fails, the monitor triggers an alert.

GraphQL Monitoring

GraphQL APIs present unique monitoring challenges. A GraphQL endpoint always responds with 200 — even when the query fails. Errors are returned in the response body as part of the errors array, not as HTTP status codes. This means a standard HTTP monitor will never detect a GraphQL failure.

Monitorion's GraphQL monitor is purpose-built for this. You provide the GraphQL query (or mutation) and optional variables. The monitor executes the query against your endpoint and checks the response for errors. Specifically, it validates:

• The response does not contain an errors array, or the array is empty
• The data field is present and contains expected values
• The response time is within acceptable bounds
• Custom assertions on specific fields in the response data

This catches query-level failures, resolver errors, schema incompatibilities, and performance issues that standard HTTP monitoring completely misses.

Multi-Step API Monitoring

Some API workflows cannot be validated with a single request. Consider an e-commerce checkout flow: authenticate, add items to cart, apply a discount code, submit the order, and verify the confirmation. Each step depends on data from the previous step — a session token, a cart ID, an order number. If any step in the chain breaks, the checkout is broken, even if every individual endpoint returns 200 when tested in isolation.

Monitorion's multi-step monitor executes a sequence of HTTP requests with variable extraction and assertion at each step:

• Step 1: POST to /api/auth/login with credentials. Extract the access_token from the response.
• Step 2: POST to /api/cart/add with the token from Step 1. Extract the cart_id.
• Step 3: POST to /api/checkout with the cart ID and token. Assert that the response contains order_id and status: "confirmed".

Cookie persistence is maintained across steps, so session-based APIs work without extra configuration. Variables extracted from one step's response can be injected into subsequent steps' URLs, headers, or request bodies. If any step fails — wrong status code, failed assertion, timeout — the monitor reports which step broke and why.

Setting Up API Monitors in Monitorion

All three API monitor types — JSON API, GraphQL, and multi-step — are available on paid plans. Here is how to set up each one:

JSON API monitor: Enter your endpoint URL, configure the HTTP method and any required headers (like Authorization: Bearer ...), and define your assertion rules using JSON path expressions. The monitor runs on your configured schedule and alerts when any assertion fails.

GraphQL monitor: Enter your GraphQL endpoint URL, paste your query in the query field, add variables if needed, and configure assertions on the response data. Monitorion handles the Content-Type: application/json header and query formatting automatically.

Multi-step monitor: Define each step with its URL, method, headers, body, and assertions. Use the variable extraction syntax to capture values from responses and inject them into subsequent steps. Test the full sequence in the monitor editor before activating.

Monitor What Matters, Not Just What Responds

A 200 status code is the bare minimum. It tells you your server is running. It does not tell you your API is working. JSON assertions, GraphQL-aware checks, and multi-step transaction monitoring close the gap between "the server responded" and "the application works." With Monitorion, you can validate every aspect of your API — from individual field values to complex multi-step workflows — and get alerted the moment something breaks. Your API consumers deserve better than status-code monitoring. Give them the real thing.