API Client — HTTP Requests with Auth & History

How the API Client Works

1. 1Choose an HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) and enter the API endpoint URL in the request bar.
2. 2Open the Auth tab to add Bearer Token, Basic Auth credentials, or an API Key — the tool builds the correct Authorization header automatically.
3. 3Add custom request headers (Accept, Content-Type, etc.) in the Headers tab and set a request body (JSON, text, or form-encoded) in the Body tab for POST/PUT/PATCH requests.
4. 4Click Send. The response panel shows the HTTP status code, latency in milliseconds, pretty-printed JSON body, and all response headers. The request is saved to your history automatically.

Authentication in HTTP APIs

Most production APIs require authentication. Bearer tokens (used by OAuth 2.0 and JWT-based APIs) are sent in the Authorization header as Bearer <token>. Basic Auth encodes username:password in Base64. API Keys can go in a header (common for REST APIs) or as a query parameter (common for third-party services like mapping or weather APIs). This tool handles all three so you never have to construct the header manually.

The Complete Guide to Testing HTTP APIs

Almost every modern application talks to APIs — fetching data, submitting forms, authenticating users, integrating third-party services. When something goes wrong, or when you are building against a new API, being able to send a request by hand and inspect exactly what comes back is one of the most valuable skills a developer can have. An API client like this one lets you do that without writing any code. This guide walks through the anatomy of an HTTP request, what the methods and status codes mean, how the main authentication schemes work, and how to debug the errors you will inevitably hit.

The Anatomy of an HTTP Request

Every HTTP request is built from four parts, and understanding them makes API work far less mysterious. The method (also called the verb) states what you want to do — read data, create it, update it, delete it. The URL identifies the resource you are acting on, and may carry query parameters that filter or modify the request. The headers are key-value pairs of metadata — what format you accept, what content type you are sending, and crucially your authentication credentials. Finally, some requests carry a body: the actual data you are sending, most often a JSON payload.

The response mirrors this structure: a status code summarising the outcome, response headers describing the result (content type, caching, rate limits), and usually a body containing the data you asked for or an error explaining what went wrong. Learning to read all three parts of the response — not just the body — is the key to efficient debugging.

HTTP Methods and What They Mean

The HTTP methods each carry a conventional meaning that well-designed APIs follow. GETretrieves data and should never change anything on the server. POST creates a new resource or triggers an action. PUT replaces a resource entirely, while PATCH updates only part of it. DELETE removes a resource. HEAD and OPTIONS are less common: HEAD fetches just the headers of a response without the body, and OPTIONS asks the server what it permits.

A concept worth knowing is idempotency — whether repeating a request has the same effect as sending it once. GET, PUT, and DELETE are idempotent (calling DELETE twice leaves the resource deleted either way), whereas POST is typically not, since posting the same order twice may create two orders. This matters when a request times out and you are unsure whether it succeeded: retrying an idempotent request is safe, while retrying a POST may need more care.

Authentication: Bearer, Basic, and API Keys

Most real APIs require you to prove who you are, and there are three schemes you will encounter constantly. Bearer tokens are the modern standard, used by OAuth 2.0 and JWT-based systems: you send a token in the Authorization: Bearer <token> header, and the server trusts anyone who “bears” a valid token — which is exactly why tokens must be kept secret and usually expire. Basic Auth is the oldest and simplest: it encodes username:passwordin Base64 and sends it in the Authorization header. Note that Base64 is not encryption, so Basic Auth is only safe over HTTPS, where the whole connection is encrypted.

API keys are a middle ground favoured by many third-party services: a single secret string that identifies your account, sent either as a custom header or appended as a query parameter. Each scheme has the same underlying goal — attaching proof of identity to the request — and this tool constructs the correct header for all three automatically, so you can focus on the request rather than the mechanics of the header.

Reading Status Codes

The status code is the fastest way to understand what happened, and the codes fall into ranges. 2xx means success — 200 OK for a normal response, 201 Created after a successful POST. 3xx means redirection. 4xx means the client (you) made a mistake: 400 for a malformed request, 401 for missing or invalid credentials, 403 when you are authenticated but not permitted, 404 when the resource does not exist, and 429 when you have been rate-limited. 5xx means the server failed — 500 for an unexpected error, 503 when the service is unavailable. Knowing these at a glance turns debugging from guesswork into diagnosis: a 401 tells you to check your token, a 429 tells you to slow down, a 500 tells you the problem is on the server's side, not yours.

The CORS Problem

One error catches nearly everyone using a browser-based API client: the request fails with a network or CORS error even though the API is working fine. This is not a bug in the tool — it is a browser security feature. CORS (Cross-Origin Resource Sharing) restricts web pages from reading responses from other domains unless that server explicitly permits it with an Access-Control-Allow-Origin header. Because this client runs in your browser, it is subject to that rule, so an API that does not opt in will have its response blocked.

The practical workaround is to move outside the browser: generate the equivalent cURLcommand and run it from your terminal, where CORS does not apply because the request is not coming from a web page. This is why an API client and a cURL generator are natural companions — use the client for quick, visual iteration against permissive APIs, and drop to cURL when CORS gets in the way or when you want a command you can script and share.

A Practical Testing Workflow

Putting it together, an efficient debugging session looks like this. Start with the simplest possible request — a GET with authentication — and confirm you get a 2xx before adding complexity. If you get a 401, check the auth tab and your token; if a 403, your credentials are valid but lack permission. Once a basic call works, layer on headers and a request body for POST or PUT calls, and read the response headers for clues like rate-limit counters and content types. Use the history feature to replay and tweak the same request repeatedly rather than rebuilding it each time. And remember that all of this happens directly between your browser and the target API — your tokens, bodies, and responses never pass through any intermediary server — so it is safe to test with real credentials.