Module · XICTRAQ

API & endpoint monitoring

Scheduled REST API checks with JSON-path assertions, header auth, response-time SLOs and alert escalation. For SaaS, integrations and internal services.

from Starter plan

Start 14-day free trial Live demo

No credit card Servers in Germany 3 EU probe nodes 14-day pro trial GDPR compliant

Live status

API & endpoint monitoring

ACTIVE

REST endpoints per interval

GET/POST/PUT/PATCH/DELETE/HEAD. Interval from 30s (Agency) to 5 min (Starter). Timeout 1-30s configurable.

Custom headers & auth

Bearer tokens, API keys, X-Request-ID — send any headers. Body payloads for POST/PUT with JSON or form data.

Status-code assertions

Exact (== 200), range (200-299), not-equal (!= 500). Granular control instead of "not 5xx".

Response-time SLOs

Response-time assertion per check: the check fails when the response time exceeds threshold X ms. History per endpoint with a response-time graph of the last 100 runs.

Last check just now

What it does

Checking uptime is only half the job — the other half is: does the API actually respond correctly? A 200 OK isn't enough if the JSON body says 'error: true'. XICTRAQ calls your endpoints on the configured interval, sends custom headers (bearer tokens, API keys), optional request bodies and checks the response against concrete expectations: HTTP status, response time, JSON-path values, text-contains checks. When two consecutive checks fail, the alert fires on the same channels as your uptime checks — email, Slack, Teams, Discord, Telegram, webhook.

REST endpoints per interval

GET/POST/PUT/PATCH/DELETE/HEAD. Interval from 30s (Agency) to 5 min (Starter). Timeout 1-30s configurable.

01 / 06

Custom headers & auth

Bearer tokens, API keys, X-Request-ID — send any headers. Body payloads for POST/PUT with JSON or form data.

02 / 06

Status-code assertions

Exact (== 200), range (200-299), not-equal (!= 500). Granular control instead of "not 5xx".

03 / 06

Response-time SLOs

Response-time assertion per check: the check fails when the response time exceeds threshold X ms. History per endpoint with a response-time graph of the last 100 runs.

04 / 06

JSON-path assertions

Check concrete values in the response body: `$.status == "ok"`, `$.data.users[0].email regex "@company.invalid$"`. Full operators: eq, neq, gt, lt, contains, regex, exists.

05 / 06

Alerts on all channels

When two consecutive checks fail, the alert fires through the same pipeline as uptime: email, Slack, Teams, Discord, Telegram, webhook, with escalation. A single outlier shows in the history but raises no alert. The history highlights failed checks, and the run-now debug output evaluates each assertion.

06 / 06

Process

How it works

Create endpoint

URL, method, interval. Optionally add headers and body. Assertions default to HTTP 200-299 — customizable via JSON editor.

Run-now button

One click, instant run with full debug output: HTTP code, response time, per-line assertion evaluation. Test before go-live.

History and alerts

History as a visual timeline directly in the dashboard. A failed assertion marks the run as “Fail” in the history and stores the reason (failure_reason). If the next check fails too, the alert goes out on your channels.

FAQ

Frequently Asked Questions

How many endpoints are included?

Free: 0 (not included). Starter: 10 endpoints, 5-min interval. Business: 25 endpoints, 1-min interval. Agency: 100 endpoints, 30-sec interval. Each endpoint counts regardless of call volume.

What assertion types exist?

Four core types: status_code (check HTTP status), response_time_ms (check duration), json_path (extract value from JSON body and check), text_contains (substring in body). Operators: eq, neq, gt, gte, lt, lte, contains, regex, in_range (e.g. "200-299"), exists. Multiple assertions are AND-combined — all must pass.

Are API endpoints checked from multiple regions?

Currently API endpoint checks run centrally from monitoring node n0. Multi-region (all three nodes n0, n1, n2 with 2-of-3 consensus) is active today for uptime monitoring and on the roadmap for API endpoint checks.

How do I stop alert floods during a known outage?

Each endpoint can be paused individually ("Pause" button). For planned maintenance, the global maintenance windows of your website settings apply.

Can I check authenticated endpoints?

Yes. Simply set `Authorization: Bearer TOKEN` in the headers field. XICTRAQ stores the header value encrypted (AES, app key). For rotating tokens, we recommend a long-lived service account token with read-only rights and narrow scope. Status codes (401, 403) are then cleanly recorded as a failure in the history.

How does this differ from regular uptime monitoring?

Uptime checks: "Is the website basically reachable?" API monitoring checks: "Does this specific endpoint also respond semantically correctly?" Example: Your checkout might return 200 but the JSON says `payment_status: "failed"`. Uptime sees green, API monitoring sees red. Together they cover the entire request lifecycle.