API Monitor & Endpoint Tester

How to Test and Monitor an API Endpoint

1. 1

   Enter the endpoint URL and choose a method, or paste a cURL command with Import cURL. Add query parameters under Params, credentials under Auth — a bearer token, Basic username and password, or an API key in a header or the query string — and any custom headers under Headers. POST, PUT and PATCH take a JSON, form, XML or text body; GET and HEAD cannot carry one, so that tab is disabled for them, which is the same rule the HTTP spec applies.

2. 2

   Set what a healthy response looks like under Assertions. The default is a 2xx status. You can also assert on a JSON path — $.data.status equals ok, $.items[0].id exists, $.balance is greater than 0 — or on a substring of the raw body for endpoints that do not return JSON. Press Run check and the result appears with each assertion marked pass or fail and the reason spelled out: "Expected $.status to equal ok, got degraded".

3. 3

   Run it a second time and the Diff tab compares the two responses. It reports structural changes separately from textual ones, because those mean different things: a timestamp moving is noise, a field disappearing or a number arriving as a string is the change that breaks your client days later.

4. 4

   If you want it watched continuously, press Monitor this on a schedule. Name it, choose an interval, set the latency above which a check counts as degraded, and optionally add an email address or a webhook URL. You get a public status page link you can share and a manage key you must save — that key is the only way to pause, edit or delete the monitor, because there is no account attached to it.

Why Use Wrklyst's API Monitor

No Signup, Not Even for the Monitoring

Every hosted uptime service wants an account before it will check a single URL. Here the one-off check needs nothing, and a scheduled monitor is identified by an unguessable manage key generated in the response — a design borrowed from our ghost accounts. No email address is required at any point unless you actually want email alerts.

The Request Runs Server-Side

A browser cannot call an arbitrary third-party API and read the answer: CORS blocks the response, and headers like Authorization, Referer and User-Agent are off limits to page JavaScript. Routing the request through our server removes both problems, which is why this works on endpoints that a browser-only tool silently fails on.

Assertions, Not Just Ping

An endpoint returning 200 with an empty body or a JSON error payload is broken, and a monitor that only watches the status code will happily report it as up for weeks. JSON path assertions check the thing you actually care about — that the field is present, that the flag says ok, that the count is above zero.

Schema Changes Alert Separately

Comparing whole response bodies fires on every check, because real APIs include timestamps and request ids. We fingerprint the structure and types instead, so a value changing is silent and a field being renamed, removed, or changed from number to string raises a distinct "changed" alert — healthy, but worth looking at. That is a different event from an outage and it is paged differently.

A Status Page You Can Actually Share

Each monitor gets a link showing uptime percentage, average and p95 response time, incident count, a 24-hour graph with the degraded threshold drawn on it, and the last dozen checks. It deliberately never shows the full URL, your headers, or any response body — only the hostname — so pasting it in a public channel does not leak your API.

Credentials Are Encrypted at Rest

Monitoring a real API means storing a real token. A saved monitor's URL, headers and body are sealed with AES-256-GCM before they touch the database, so a stolen dump is inert. We are explicit that this is not end-to-end encryption — our checker has to send the request, so it can open the envelope — and we would rather say that than imply more.

When You'd Reach for This

The tester and the monitor get used at different moments, usually by the same person a few minutes apart.

Debugging a CORS-Blocked Request

Your fetch fails in the browser console and you cannot tell whether the API is broken or the browser is refusing to show you the answer. Running the same request server-side gives you the real status and body in one step.

Verifying a Deploy

Paste the endpoint after a release, assert on the version field in the response, and confirm the new build is actually serving before you tell anyone it shipped.

Watching a Third-Party Dependency

Your product depends on someone else's API and their status page is optimistic. Monitor the specific endpoint you call, with the assertion you rely on, and find out before your users do.

Catching a Silent Contract Change

A provider renames a field or starts returning a number as a string in a minor release. Nothing 500s, nothing alerts, and your parser breaks. The changed alert is the one that catches this.

A Status Page for a Side Project

You want somewhere to point users when they ask whether the API is down, without running a status-page product for a project with eleven users. The shareable link does that.

Checking a Webhook Receiver

Send a representative POST body to your own webhook endpoint and confirm it responds correctly, which is awkward to do repeatedly from a terminal and impossible from a browser tab.

How It Compares

Endpoint testing and uptime monitoring are usually sold separately, and both usually want an account first.

Getting More Out of Endpoint Monitoring

• Monitor a dedicated health endpoint that touches your database and your critical dependencies, not the homepage. A static page returning 200 while the database is unreachable is the classic false-green.
• Add a JSON path assertion on the field that actually indicates health. Plenty of APIs return 200 with {"status":"degraded"} in the body, and only an assertion catches that.
• Set the degraded threshold near your real p95, not at a round number. The point is to notice the day latency doubles, which a 5000 ms threshold on a 120 ms endpoint never will.
• Use a webhook into Slack or Discord for the team channel and email for yourself — the webhook payload includes the reason, the status code, the response time, and the specific schema changes.
• Keep the failure threshold at two or higher for anything on the public internet. Single-check alerting on a five-minute interval mostly teaches people to ignore the alerts.
• Run the check twice in the tool before you save the monitor, and read the Diff tab. If two consecutive responses already differ structurally, the changed alerts will be noisy and you want to know that now.

Frequently asked questions