Testing REST APIs in the browser, explained
An API tester (or REST client) lets you send an HTTP request by hand and see exactly what comes back: the status code, the headers and the body. That is how you try out an API before writing code, check what an endpoint returns, reproduce a bug or confirm that a token works. This one runs entirely in your browser: no account, no install and no server in between, so your requests and tokens go only to the API you call.
HTTP methods
| Method | Used for | Body | Safe to repeat |
|---|
| GET | Read a resource or a list | No | Yes |
| POST | Create something or run an action | Yes | No |
| PUT | Replace a resource completely | Yes | Yes (idempotent) |
| PATCH | Change part of a resource | Yes | Not guaranteed |
| DELETE | Remove a resource | Rarely | Yes (idempotent) |
| HEAD | Headers only, no body | No | Yes |
| OPTIONS | Ask what is allowed (used by CORS preflights) | No | Yes |
Reading the status code
2xx means success: 200 OK, 201 Created, 204 No Content. 3xx is a redirect, which the browser follows unless you turn that off. 4xx means the request was wrong: 400 for a malformed request, 401 when authentication is missing or invalid, 403 when you are known but not allowed, 404 for a wrong path, 415 for the wrong Content-Type, 422 for a body that fails validation and 429 when you hit a rate limit. 5xx means the server failed. For each error the tester shows a short explanation above the body.
Why do some requests fail with CORS?
Browsers protect you with the same-origin policy: a page may send a request to another domain, but it can only read the answer if that server allows it with Access-Control-Allow-Origin. That is CORS. Public APIs usually allow it; internal and admin APIs often don't. Requests that use methods other than GET, HEAD and POST, custom headers such as Authorization, or a JSON Content-Type are preflighted: the browser first sends an OPTIONS request and only continues when the server agrees. The Timing & CORS tab tells you whether your request needs a preflight and why. When CORS blocks a call, the browser only reports "Failed to fetch"; copy the request as cURL and run it in a terminal to see the real answer, since CORS only exists in browsers.
What a browser won't let you do
Some things only a desktop client or cURL can do. Browsers drop forbidden headers such as Host, Origin, Referer, Cookie and Content-Length, and the tester warns when you add one. A secure https page can't call plain http:// addresses, except localhost. Cross-origin responses only expose a few headers unless the server lists more in Access-Control-Expose-Headers, and cookies are never readable. Self-signed certificates are rejected. For local development servers, add CORS headers or use cURL.
Authentication: Bearer, Basic and API keys
Bearer tokens (OAuth 2.0 access tokens, often JWTs) go in Authorization: Bearer <token>. When the token is a JWT, the tester decodes it locally and shows its audience, scopes and expiry, which explains many 401 errors at a glance. Basic auth sends username:password encoded in Base64; that is encoding, not encryption, so only use it over https. API keys go in a header such as X-API-Key or in the query string, depending on the API.
Environments and variables
Write {{base}}/users instead of the full address and define base once per environment, for example development, test and production. Switching the environment switches every request. Built-in variables generate a fresh {{$uuid}}, {{$timestamp}}, {{$isoTimestamp}} or {{$randomInt}} on every send, which is handy for idempotency keys and unique test data.
From cURL and to code
Most API documentation shows examples as cURL, and every browser can copy a network request as cURL (DevTools → Network → right-click → Copy → Copy as cURL). Paste such a command into the URL field and the method, URL, headers, body and Basic or Bearer auth are filled in. The other way round, the Code tab turns the current request into cURL, JavaScript fetch, Python requests or PowerShell Invoke-RestMethod.
Your data stays with you
History, saved collections and environments are kept in your browser's local storage, including any tokens you type. On a shared computer, use variables for secrets and clear them when you are done. A shared link holds the request in the part after the #, which browsers never send to a server, and leaves out the Auth tab unless you tick the box.