Documentation

An API check is a short list of HTTP requests that run in order. Each step sends one request and checks the response against assertions you write, and a step can also pull values out of its response — a token, an ID — for later steps to use. The check is UP only when every step it ran passed. One request with one assertion is an HTTP monitor job; a login followed by a call that needs the token is this one.

What It Is For

What It Is Not For

This monitor is a sequence. If you do not need a sequence, something else is a better fit:

How a Check Runs

1. The steps run in the order they are listed, from the top. A monitor may hold up to 50 of them.
2. Before each request, {{variable}} placeholders are replaced with what is known so far — values you defined up front, plus everything extracted by earlier steps.
3. The step URL is checked: it must be http or https, and it must not resolve to a private, loopback or link-local address.
4. The request is sent. Redirects are followed unless the step says otherwise.
5. The assertions on that step are evaluated, all of them, and then the step’s variable extractions run.
6. If the step failed and Stop on failure is on — it is by default — the remaining steps are skipped.

Two numbers end up on the check: the response time is the time of the whole run, every step together, and the HTTP status shown is the one from the last step that produced a status code.

What a Step Can Check

Assertions are what make a step pass or fail. A step with no assertions at all passes on any response it gets, including a 500 — so every step needs at least one.

The operators are: equals, not equals, contains, does not contain, matches (a regular expression), less than, less than or equal, greater than, greater than or equal, exists, does not exist. Everything is compared as text except the four size operators, which read both sides as numbers and fail the assertion if either side is not one. So a status code asserted as 200 and as "200" behave the same.

Passing Values Between Steps

This is the part a plain HTTP monitor cannot do. A step declares what to pull out of its response and under what name; later steps write {{name}} wherever the value belongs. Names are letters, digits and underscores. A name nobody defined is left in the text exactly as written, which is usually visible in the failure that follows.

Each extraction can carry a fallback value, used when the extraction finds nothing.

A placeholder is replaced in four places: the step URL, the values of that step’s own headers, the request body, and the authentication fields (token, user name, password). It is not replaced in headers you set globally for all steps, and it is not replaced in the expected value of an assertion — you cannot assert that a response equals a variable. Put anything that has to carry a variable into the step’s own headers.

Status Logic

The check is UP only when every step that ran passed. There is no degraded state for this monitor: a rate-limited or slow API fails whichever assertion catches it, or passes.

DOWN and TIMEOUT both count as downtime and both open an incident — after the confirmation threshold, three consecutive failing checks by default, so one bad deploy minute does not page anyone.

The error message recorded on the check is the message from the failing step, with up to three failed assertions joined together — for example Status code 500 did not match equals 200. It says what failed, but not which step it was, so give each step a name you will recognise and keep the assertions on a step distinct enough to tell apart. Per-step results are not stored with the check either: one status, one total time, one message.

A step PingZen cannot read at all fails the whole check, and nothing is sent: the message names the step, as in API check misconfigured — 1 of 3 steps are misconfigured (step 2: missing required field(s): url). One unreadable step out of several is enough — a workflow that cannot run everything you configured is not allowed to report up. The form and the API also refuse such a configuration when you save it, so this only appears on monitors written before that check existed.

Configuration

Because tokens and passwords live inside this configuration, it is left out of CSV export of your monitors. Import still accepts it if you fill it in yourself.

What the Form Does Not Show

The step editor in the monitor form covers steps, methods, URLs, a request body for POST, PUT and PATCH, and assertions. Everything else this page describes exists in the monitor but has no input in the form, and is set through the REST API or the MCP tools on the same monitor: request headers, variable extraction, starting variables, authentication, per-step timeouts, redirect handling, and the per-step “continue anyway” flag. Editing a monitor in the form keeps those values — the editor writes back the fields it knows and leaves the rest alone.

Two more gaps worth knowing before you build a flow in the form:

• A body typed in the form is sent as raw text with no Content-Type header. An API that requires application/json will reject it. Add the header through the API — as a global header or on that step — or send the body as a JSON object rather than text, which sets the header itself.
• The assertion operator list in the form is shorter than what the check supports. Less-than-or-equal, greater-than-or-equal, exists and does not exist work, but only through the API.

And two settings that exist in the configuration but do nothing today, so do not plan around them: an API key placed in the query string instead of a header is never added to the URL, and turning off certificate verification on a step has no effect — certificates are always verified.

Key Features

• Up to 50 HTTP requests in one monitor, run in order, with the whole sequence passing or failing as one check
• Values extracted from a response — a token, an ID, a header, a cookie — carried into later steps as {{variables}}
• Six assertion types per step, including JSONPath into the response body, and eleven operators
• Per-step authentication (bearer, basic, API key, custom header) that can use an extracted token
• Stop at the first failing step, or run them all and report what broke
• Step URLs are restricted to public http and https addresses, so a monitor cannot be pointed at internal infrastructure