The API answers 200 and returns a login page
A session expired, so the endpoint now serves HTML instead of JSON. The status code is 200, the response time is fine, and the integration on the other side has been broken since Tuesday.
Three questions, in the only order that works
The three readings form one chain rather than three independent tests, and the order is not a preference. Without a successful parse there is no field to look for; without the field there is no value to compare. Each answer only makes sense once the previous one succeeded.
| Reading | The failure it names | What you configure |
|---|---|---|
| Is it JSON at all | An HTML login page, an error page, a truncated response. | Nothing. This one needs no settings. |
| Is the field there | A field renamed or removed by an update, in a response that is still valid. | The path to the field, which may walk through a list by index. |
| Does it say what it should | A health endpoint that answers, and answers "maintenance". | The expected value, compared as text. |
The three verdicts and the order between them live in src/Regle/ReponseJson.php, read on 3 August 2026.
An endpoint a cache cannot answer
This is where a JSON check earns its place on a site that is not an API at all. A page cache can serve a WordPress front page for hours after the database stopped answering, so every reading taken on that page looks correct. An endpoint that has to query the database to reply at all cannot be served from that cache.
So the path walks into the list the REST API returns and asks for the first record's identifier. If a real number comes back, something read the database within the last second. It is the cheapest proof of life there is, and it is the reason this reading exists on sites that never expose an API to anyone else.
An empty body says nothing here
When the endpoint returns no body, no JSON verdict is raised at all. That is deliberate: the outage is already named by the network or the status code, and a second verdict for the same incident would produce two alerts where there is one problem.
It also matters which of the two survives. The vaguer alert is always the louder one, so it is the one that ends up quoted in a summary and the one that sends somebody looking in the wrong place. Keeping the precise verdict means keeping the one that names the cause.
Where the others land on this
Checkly is built for this and does it far better: scripted chains, tokens carried between requests, assertions on whole schemas, runs from several regions. If your problem is an authenticated multi-step flow, that is the tool, and this is not trying to be it.
What this offers instead is one endpoint watched next to the pages of the same site, in the same queue, with no code to write. The difference is scope and effort rather than depth, and for the endpoint a site quietly depends on, it is usually the difference between watched and not watched.
Questions about watching an endpoint
What breaks in a way a status code cannot show?
The two failures that actually happen. A session expires and the endpoint answers 200 with an HTML login page, which is valid HTTP and useless JSON. Or an update ships and the field your integration reads has been renamed, so the response is perfectly well-formed and no longer contains the one thing you needed. Both look healthy to anything that stops at the code.
Can the path reach into a list?
Yes, by index, and that case is the reason it exists. The WordPress REST API returns an array of pages, so the path to the first record's identifier walks through position zero. That is exactly the check used to prove a WordPress is really serving its database rather than a cached page, because a cached page cannot answer an endpoint that has to query to reply.
What happens when the endpoint returns nothing at all?
Nothing is said about the JSON, deliberately. An empty body is already reported by the network or status-code reading, and adding a second verdict for the same outage would put two alerts on one incident. The louder of the two is always the vaguer one, so it would be the one quoted in the summary.
Do I have to give it a field, or is the shape enough?
The shape alone is a valid check: an endpoint that stops returning parseable JSON is already a failure worth hearing about, and that needs no configuration. Naming a field narrows it to what your integration actually depends on, and naming an expected value narrows it again, to a health endpoint that must say "ok" rather than merely answer.
Is this the same as an API monitoring product?
No, and it is smaller on purpose. A dedicated API tool will chain requests, carry a token between them, assert on schemas and run from several regions. This reads one endpoint, one field, one value, alongside the pages of the same site. If you are testing a multi-step authenticated flow, buy the dedicated tool; if you want to know that the endpoint your site depends on still answers with real data, this is already watching it.
Try it on a page first
The free check reads the body as well as the code, and tells you when the two disagree. One address, no account.