Back to all free tools

API Tester

Send a real HTTP request from a probe and inspect the response — status, headers and every JSON field.

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Start free

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is API Tester?

An API tester sends a real HTTP request to an endpoint and shows you the whole response — not just whether it answered, but the exact status, headers, timing, and every field in the body. It's how you answer the question a browser can't: *is the API returning what it's supposed to?* An endpoint can respond 200 OK and still be broken — a health field flipped to "degraded", a list that lost its items, a total that quietly dropped to zero. You only see that by reading the response.

This one runs the request from a monitoring probe, not your browser — so there are no CORS restrictions. A browser fetch to a third-party API is blocked unless that API explicitly allows your origin; here the request originates server-side, the same way a backend or a monitor reaches the endpoint. You get the raw response a real client sees, from a real network location.

How it works

Every request you send follows the same path a monitor would:

  1. 1Build the request — Pick the method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), add any headers, and — for write methods — a request body. Anonymous runs are limited to GET / HEAD / POST; a free account unlocks the rest.
  2. 2Run it from a probe — The request goes out from one of our monitoring locations over a real TCP (or HTTP/3) connection with full TLS — no CORS, no browser sandbox. Free runs use the region nearest you; paid plans can pick the exact region to test geo-routing and CDN behaviour.
  3. 3Capture the whole response — Status code and reason, per-phase timing, body size, HTTP version, every response header, and the body itself — captured exactly as the server sent it.
  4. 4Flatten the body into fields — If the response is JSON, the body is flattened into a clickable list of every path and value (resources.core.remaining → 60), so you can scan the whole shape at a glance instead of eyeballing raw text.

Nothing is transformed or "helpfully cleaned up" — the status, headers and body are exactly what the endpoint returned, from the region it was reached.

When you'd use it

Post-deploy verification

You shipped a new version of an API. It returns 200, so the deploy is green — but is the *payload* right? Send a request and check the actual fields: the version bumped, the feature flag is on, the list isn't empty. A status code can't tell you any of that.

"Works on my machine, not in prod"

A call that succeeds from your laptop fails from a server — often CORS, a missing header, IP allow-listing, or geo-routing. Running from a probe (no CORS, a real server IP, a chosen region) reproduces exactly what your backend or a user in another country sees.

Inspecting a third-party API

You're integrating against an API whose docs are thin. Send a request and read the real shape — which fields exist, what the headers say about rate limits and caching, whether it's behind a CDN — before you write a line of parsing code.

Reproducing a bad response

A customer reports a wrong value. Fire the same request and see the live body — is the field actually wrong at the source, or is it your caching/parsing? The flattened field list makes the answer obvious.

Reading the result

Status + timing + size

The hero number is the HTTP status (2xx good, 4xx/5xx a problem). Next to it: how long the request took and how big the body was — a sudden jump in size often means an error page or an unexpected payload snuck in behind a 200.

Fields

For JSON, every leaf value is listed by its path — data.items.0.name, resources.core.remaining. Scan for the one that's wrong; you don't have to hunt through nested braces.

Headers

The full response header set — Content-Type, cache directives, rate-limit headers (X-RateLimit-Remaining), CDN fingerprints, security headers. Often the header tells the story the body doesn't.

Common pitfalls

Expecting CORS to matter

It doesn't here — that's the point. This runs server-side, so an API that blocks browser fetch still works. If your browser code fails but this succeeds, your problem is CORS, and the fix is on the API's Access-Control-Allow-Origin, not the request.

A body on GET

A request body on GET is non-standard and most servers ignore it. We'll still send it (some APIs, like Elasticsearch, read a GET search body), but if your body seems to have no effect, the method is usually why.

Pasting credentials

This public tool never asks for auth headers — a checker page shouldn't invite you to paste bearer tokens. To test an authenticated endpoint, use it inside a signed-in [API monitor](/api-monitoring), where secrets are encrypted at rest.

Treating `200` as "correct"

A 200 means the server answered, not that the answer is right. Always read the body. This is exactly why one-off testing isn't enough — a field can flip to a bad value at 3am with the status still green.

Run API Tester on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

Is the API tester free?
Yes. GET, HEAD and POST requests run with no signup, rate-limited per IP. A free account unlocks every method and higher limits.
Why run from a server instead of my browser?
A browser fetch to a third-party API is blocked by CORS unless that API allows your origin. Running server-side removes that limit and shows the response a backend or monitor actually receives — from a real network location, not your machine.
Can I choose which region the request runs from?
Free runs use the location nearest you. Paid plans can pick a specific region — useful for testing geo-routing, CDN edges and region-specific responses.
Can I send headers and a request body?
Yes — add any request headers, and a body for POST / PUT / PATCH. The response comes back with its full headers and body.
How is this different from Postman or curl?
Same idea, but the request runs from a monitoring region (no CORS, a real server IP), the JSON body is flattened into a searchable field list, and one click turns the request into a scheduled monitor with assertions and alerts.
Can it test an authenticated API?
The public tool intentionally doesn't take credentials. To test endpoints behind auth — basic, digest or bearer — use an API monitor in the dashboard, where auth is stored encrypted.
Does it follow redirects and support HTTP/3?
Yes — it follows redirects and negotiates HTTP/2 or HTTP/3 where the server offers it, over a full TLS connection, just like a real client.
How do I keep watching an endpoint, not just test it once?
Turn it into an [API monitor](/api-monitoring): it runs the request on a schedule from regions worldwide, asserts on the JSON fields and headers, extracts numbers into charts, and alerts you the moment the response goes wrong.

Related web tools