REST API Tester

GET asks for something and should change nothing, which is why the same GET can be repeated safely. POST creates or triggers, and repeating it usually creates a second thing. PUT replaces a resource with what you send, so anything left out is gone. PATCH changes only the fields you include. DELETE removes. HEAD is a GET that returns headers with no body, handy for checking a large file's size or type without downloading it. The request body box only appears for the four methods that carry a payload, since GET and HEAD send none — an API expecting data inside a GET is unusual enough to be worth checking twice.

Cross-origin rules are enforced by the browser, not by the server. A request issued from a server has no origin to check, so it goes through whatever the API permits; your front-end code is checked against the Access-Control-Allow-Origin header the API returns and blocked when it does not match. That is why an endpoint can answer perfectly in a tester and fail in your page with a console error and no readable response at all. Open the Headers tab and look for the allow-origin header. If it is missing, the fix belongs on the API side or in a proxy you control, not in your JavaScript.

The form is posted to a route on this site, and the request is re-issued from that server, so the endpoint sees the server's address rather than yours. The reply comes straight back in the same response and no copy is kept — there is no request history here and nothing to return to later. The headers box is what deserves care: an Authorization header you type is forwarded to the target exactly as written, which is the only way it could work, and that token has then been used from outside your own machine. Prefer a short-lived or read-only credential, and rotate anything sensitive afterwards.

No, and the refusal is deliberate. The hostname is resolved before anything is sent and every address it returns is inspected; loopback, link-local and private ranges such as 10.x, 172.16 to 172.31.x and 192.168.x are rejected with a message saying the URL points to a private or local network address. Every address is checked rather than only the first, so a hostname holding both a public and a private record is refused as well. A server that will fetch any URL handed to it is otherwise a route into whatever sits behind it. For a local API, use a client running on that same machine.

A 401 means the server did not accept your identity: no credential, an expired token, a malformed Authorization header. A 403 means it knows who you are and refuses anyway — the key is valid but lacks the scope, the plan does not cover the endpoint, or the account cannot touch that record. Repeating a 401 with the same token is pointless, while a 403 is a permissions or billing question rather than a login one. Two details catch people out: the header value is Bearer followed by a single space, and a newline picked up while copying a token breaks it. A 404 on an authenticated endpoint is sometimes a 403 in disguise.

Because the body and the headers are separate. Only the headers you type are forwarded, and nothing is inferred from what sits in the body box, so a JSON payload arrives without a Content-Type of application/json unless you add that line yourself. Plenty of APIs answer 400 or 415 to that, and the message rarely names the real cause. Add Accept: application/json on the same principle when you want JSON back. The other common cause is that the payload is not valid JSON at all: a trailing comma, a curly quotation mark pasted out of a document, or single quotes around keys will each be rejected by a strict parser.

Redirects are not followed here, so a 301 or 302 arrives as itself with a body that usually looks empty, and the Location header in the Headers tab tells you where it wanted to send you. Paste that value into the URL box to carry on. Seeing the hop rather than skipping it is often the useful part: an http address quietly upgraded to https, a URL missing its trailing slash, or an old API version pointing at a newer one are all things a client that follows redirects hides from you. Method matters too — a 302 makes many clients turn a POST into a GET, while 307 and 308 preserve it.

A request is abandoned after ten seconds and reported as a timeout, so anything slower than that cannot be measured here whether or not it would eventually have answered. A timeout usually means one of three things: the host is not accepting connections, the endpoint is genuinely slow, or the API is holding the connection open on purpose, as long-polling and streaming endpoints do. The millisecond figure beside the status is a round trip measured from the server with connection setup included, not what someone on a mobile connection would experience. Treat it as a rough comparison between calls rather than a performance measurement.