Know your API answers correctly, not just that it answers
Most API failures do not look like failures to a status-code check. The framework catches the exception and answers 200 OK with {"error": "database unavailable"}. A broken import leaves the product list empty. A cache keeps serving old data after the job that fills it has died. Each of these is "up" — and each is broken for every client that calls it.
Pingsured reads the JSON in the response and checks the values that tell you whether the API is actually working.
What to check
A health endpoint that reports its dependencies is the easiest place to start. If it answers {"status": "ok", "db": "ok", "queue": {"depth": 12}}:
| JSONPath | Operator | Value |
|---|---|---|
$.status | equals | ok |
$.db | equals | ok |
$.queue.depth | less than | 1000 |
The last line is the one a status code can never give you: the API is up, and the work behind it is not piling up.
For an endpoint that returns data rather than a status, check the shape of the data itself:
| JSONPath | Operator | Value |
|---|---|---|
$.items[*] | count at least | 1 |
$.items[0].price | greater than | 0 |
$.generated_at | age less than | 900 |
An empty list, a price of zero and a response older than fifteen minutes each fail the ping, while the server keeps answering 200.
Endpoints that need credentials
Add the headers the API expects — an Authorization: Bearer token, an API key header — or HTTP basic authentication. Give the check its own read-only token: it is stored with the ping, and a token made for monitoring can be revoked without breaking anything else.
Why check your API with Pingsured
- Typed comparisons. The number
12does not equal the string"12", so a serialisation change that turns numbers into strings — and breaks every strictly typed client — fails the check instead of slipping through. - Freshness without a script. The age operators read ISO 8601 timestamps, HTTP dates and Unix time, so "the data is less than an hour old" is one line, not a cron job you have to monitor as well.
- Up to 16 JSON checks per ping, combined freely with the status code, a header check and a text match. The ping passes only when all of them do.
- Checked from where your clients are. Each location is judged on its own, so an API that fails behind one CDN edge or from one region is not hidden by the others.
- Alerts where you work. Email and the app by default; on the Team plan and above, a webhook into your incident tool or chat.
- Your API's details stay in the EU. Endpoints, headers and tokens are part of what a monitoring account stores. Pingsured stores them in Germany and Finland, with no US service involved.
Limits worth knowing
- Checks send
GETorHEAD. An API that is only reachable withPOST— most GraphQL setups, SOAP — cannot be checked yet. - Each check is one request. A flow that logs in first and then calls the API with the resulting session is not possible; a long-lived token in a header is.
- Only the first 1 MB of the response is read, and JSON cut off there no longer parses. Point the check at a small endpoint or a page of a list, not at a full export.