API Request Tester

What this is for

You have an endpoint and a question: does it work, does my token authenticate, what shape does the response actually take? Set it up above and send it. You get the status code, the response headers and the body, which is everything you need before you commit to a mapping in code or in an automation platform.

For saved collections, environments and team sharing, a desktop client is the better tool. For the single call you need to understand right now, opening a browser tab beats configuring a workspace.

A worked example: verifying a webhook receiver

Say you have built a receiver at https://api.example.com/hooks/lead and you want to know it behaves before pointing a live form at it.

Send the happy path first. POST, header Content-Type: application/json, body:

{ "name": "Sam Doe", "email": "sam@example.com", "source": "site-form" }

You want a 200 or 201 back quickly. Anything over about two seconds and the sending platform may time out and retry, which means duplicates.

Then send it wrong on purpose. Remove email and send again. A 400 with a message naming the missing field is a receiver you can trust. A 200 means it accepted a lead with no email address, and you have just found the bug before it found you. Send the same body twice with the same identifier — if you get two records, the endpoint is not idempotent and any retry from the sender will duplicate data.

Then send it with no token. A 401 is correct. A 200 means the endpoint is open to the internet.

Three requests, perhaps four minutes, and you know more about that endpoint than most integrations ever establish about the ones they depend on.

Reading the response

The status code is defined in RFC 9110, which is the current HTTP semantics specification.

The distinction that matters when you build the retry logic: retry the 5xx range and 429, never the 4xx range. A 400 will fail identically a thousand times.

The failure that confuses everyone: CORS

A request that works from the command line and fails from a browser is almost never an authentication problem. Browsers enforce cross-origin resource sharing: unless the server returns Access-Control-Allow-Origin covering the calling page, the browser blocks your code from reading the response — even though the request was sent and the server answered.

Two consequences worth internalising. First, a "non-simple" request such as a POST carrying Content-Type: application/json triggers a preflight OPTIONS call first, so an API that rejects OPTIONS breaks in the browser and nowhere else. Second, and this is the important one, CORS is not a security control for your credentials. It stops other websites reading a response in a user's browser. It does nothing to protect an API key you put in front-end code — anyone can read that in devtools and call your endpoint from a server, where CORS does not apply. Keys belong on a backend.

Mistakes worth avoiding

Testing against production. Use the sandbox. A DELETE sent to the wrong environment is a bad way to learn this.

Pasting a live token into a hosted tester. Use a scoped, short-lived test token. Rotate anything you have pasted anywhere you do not control.

Assuming an empty response body means failure. A 204 is a success with no content by design.

Trusting one call. Endpoints behave differently under a rate limit, on the second identical request, and when a field is missing. Test all three, not just the one that works.

Ignoring the response headers. Retry-After, X-RateLimit-Remaining and the pagination links live there, and every one of them changes how your integration should be written.

Frequently Asked Questions

Do my requests and tokens go through your server?

Requests are sent from your browser. Treat any credential you paste into any online tester as exposed regardless, and use a test key with the narrowest scope you can — that is sound practice whoever built the tool.

Why does the same request work in my terminal but fail here?

CORS, almost always. curl is not a browser and does not enforce it. See the section above. The request reached the server either way; the browser simply will not let the page read the answer.

Can I test a webhook that my own machine receives?

Not directly — this sends requests, it does not receive them. Point a tunnel such as ngrok at your local server to get a public URL, then send requests to that. The n8n Webhook Tutorial covers the full loop, including why the test URL and the production URL behave differently.

How do I test an API with OAuth?

Get an access token through your OAuth flow first, then send it here as Authorization: Bearer <token>. This tool is for the authenticated call, not for the token dance. Remember that access tokens usually expire in an hour, so a request that worked earlier and now returns 401 may need nothing more than a fresh token.

What should I check before wiring an endpoint into an automation?

Four things: the success response shape, the error response shape, the rate limit headers, and whether repeating a request creates a duplicate. Get those wrong and the workflow will look fine in testing and misbehave in production. The Make.com HTTP Module Tutorial walks through wiring an API with no native connector once you have those answers.

Next steps

If the response you are inspecting is deeply nested, the JSON Formatter makes the paths obvious, and API Automation for Businesses covers what a production-grade integration needs beyond the happy path.

If you would rather have the integration built properly the first time — retries, backoff, idempotency, the lot — I take this on as a freelancer: start a project on Fiverr or hire me on Upwork.