A 200 OK doesn't mean your API works. Bayqus asserts what's actually in the response.
Plain uptime checks stop at the front door: the endpoint answered, so it's "up." But an API can return a perfect 200 while handing back an error object, an empty list, a stale token or a payload that's three times too slow. Bayqus' API monitor fires a real request and then checks the response against assertions you set — status, latency, a value inside the JSON, a header, the raw text. It's up only when every one of them passes.
It's an uptime check that reads the answer, not just the door.
API monitoring is a check type in Bayqus' external uptime layer — the same layer that runs your HTTP, keyword, ping, TCP and SSL monitors from outside your network. The difference is what counts as "up." A normal HTTP check is satisfied by a successful response. An API check runs your assertions against that response and only reports up when all of them hold — so the class of outage where the service answers but answers wrong finally becomes visible.
Plain HTTP check — looks fine
GET /api/orders → 200 OK
{ "ok": false,
"error": "db_unavailable",
"orders": [] }
Status is 200, so a plain check reports Up. The outage is invisible.
API check — catches it
GET /api/orders → 200 OK assert body.ok eq true ✗ assert status eq 200 ✓ assert latency < 800ms ✓
One assertion fails, so the monitor is Down — and you're alerted.
Five things to read, eleven ways to compare them.
Each assertion picks a source from the response and compares it with an operator. Add as many as you like — every assertion must pass for the check to be Up. A JSON body assertion also takes a dot-path (e.g. data.status) to reach into the payload; a header assertion takes the header name.
| Source | Reads | Example assertion |
|---|---|---|
| status | HTTP status code | status equals 200 — or not equals 500. |
| latency | Response time, in ms | latency less than 800 — a soft SLA on the endpoint itself. |
| body | A dot-path into the JSON body | data.status equals "ok"; orders exists. |
| header | A named response header | content-type contains "application/json". |
| text | The raw body text | body text matches a regular expression, or does not contain "traceback". |
Single request for an endpoint. Multi-step for a journey.
Most APIs need one call. Some need a sequence — log in, take the token, call the protected endpoint. Bayqus does both.
Single request default
Choose the method, add an optional request body and any headers, then attach assertions. One HTTP request goes out each interval; the monitor is Up only when every assertion passes.
- Any method — GET, POST, PUT, PATCH, DELETE…
- Optional JSON (or any) request body
- Custom request headers for auth
- A configurable per-check timeout
Multi-step flow Team
Chain several requests that run top to bottom. Each step can extract a value from its response into a variable, and later steps interpolate it into their URL, headers or body with {{…}}.
- Reference earlier data:
{{token}},{{steps.login.body.data.id}},{{steps.login.status}} - Per-step assertions and variable extraction
- Checking stops at the first failing step
- Reported latency is the sum of the steps
- A per-step result breakdown shows exactly where a flow broke
Credentials stay encrypted, and never leave the primary location.
The things people ask first.
Q. How is this different from a plain HTTP monitor?
A plain HTTP monitor calls the URL and treats any successful response as up. An API monitor evaluates assertions against the response — status, latency, a value in the JSON body, a header, or the raw text — and is up only when all of them pass. That's what catches the 200 OK that's quietly returning the wrong thing.
Q. Can I check a value deep inside the JSON body?
Yes. A body assertion takes a dot-path such as data.status or result.items, and you can assert that it equals a value, contains text, matches a regex, or simply exists. It's the most common way to confirm the API returned real data and not an error envelope.
Q. How do I monitor an endpoint that needs a login first?
Use a multi-step check. Make the first step your login call, extract the token from its response into a variable, then reference {{token}} in the Authorization header of the next step. Steps run in order and stop at the first one that fails, so the breakdown tells you whether login or the protected call broke.
Q. Are my API keys safe?
Headers and request bodies are encrypted at rest with AES-GCM and masked on read. Editing a monitor and leaving a value blank keeps the existing secret. API checks also run only from the primary location, so credentials are never sent out to remote vantage points.
Q. Which plan do I need?
API monitoring is part of the Team plan — the Free plan includes zero API monitors. Team unlocks API checks with response assertions and multi-step flows, on top of your device, SNMP and standard uptime monitoring.
More on how it fits together
Stop trusting the status code. Assert the response.
Add an API monitor from the portal, attach a few assertions, and let Bayqus catch the outages a plain uptime check sleeps through.
Start free Talk to usLast verified against the uptime engine (uptime/src/checks/api.js) and backend (backend/src/routes/uptime.js) — 2026-07-21