How to Test an API: A Beginner’s Guide to HTTP Requests

The method tells the server what kind of operation you’re asking for. Using the right one matters — some APIs reject the wrong method outright, and using GET for something that changes data is a common source of confusing bugs (browsers and proxies are allowed to cache or re-run GET requests, which is unsafe if a GET is secretly deleting something).

• GET — fetch data, no side effects. Should be safe to repeat.
• POST — create something new, or trigger an action that isn’t a simple update.
• PUT — replace a resource entirely with what you send.
• PATCH — update part of a resource, leaving the rest as-is.
• DELETE — remove a resource.
• HEAD — same as GET but returns only headers, no body; useful for checking if something exists without downloading it.
• OPTIONS — asks the server what methods/headers are allowed; browsers send this automatically as a CORS "preflight" before certain cross-origin requests.

These three carry different kinds of information, and mixing them up is one of the most common reasons a request that "looks right" still fails.

Query parameters (the ?key=value part of a URL) are for filtering, pagination, or options that identify what you want — page=2, sort=name, format=json. They’re visible in logs and browser history, so avoid putting secrets there.

Headers carry metadata about the request itself: what format you’re sending (Content-Type), what you’ll accept back (Accept), and authentication (Authorization). They describe the request, not the data being acted on.

The body carries the actual data for POST, PUT, and PATCH — the new record, the updated fields, the file being uploaded. GET and HEAD requests conventionally don’t have one; sending a body with GET works in a browser-based tool, but many servers and proxies will ignore or reject it.

What you set as the body needs to match what the API expects, signaled by the Content-Type header.

• JSON (application/json) — the most common format for modern APIs; a plain JSON object or array as the body.
• Form URL Encoded (application/x-www-form-urlencoded) — key=value pairs joined with &, the same format a plain HTML form submits.
• Multipart Form Data (multipart/form-data) — required when uploading files alongside other fields; each part of the body is a separate named field.
• Plain text — anything that isn’t structured data: a raw string, XML, CSV, or another custom format the API expects verbatim.

Most non-public APIs require proving who you are on every request, since HTTP itself has no memory between requests.

• Bearer token — an Authorization: Bearer <token> header; the most common scheme for modern APIs (OAuth access tokens, API tokens, JWTs).
• Basic auth — a username and password combined and base64-encoded into the Authorization header; older but still common for internal tools and simple APIs.
• API key — a token sent either as a custom header (X-API-Key is a common name) or as a query parameter, depending on what the provider expects.

The status code is the first thing to check — it tells you the outcome before you even look at the body. 2xx means success, 3xx means redirect, 4xx means the request itself was the problem (bad input, missing auth, not found), and 5xx means the server failed while handling an otherwise-valid request.

Response headers often carry information the body doesn’t: Content-Type tells you how to parse the body, rate-limit headers tell you how many requests you have left, and caching headers tell you how long the response is valid for.

The body is the actual data (or error message) the API sends back — usually JSON for modern APIs, which is worth viewing pretty-printed rather than as one unbroken line once responses get any size to them.

Once you’re testing the same endpoint repeatedly — tweaking a header, retrying after a fix — rebuilding the request from scratch each time wastes the exact minutes a request builder is meant to save. Saving a request with a name (like "Login" or "Create User") turns it into a one-click resend instead.

Local history serves a different purpose: a running log of exactly what you sent and got back, useful for comparing "what changed" between a working attempt and a broken one.

cURL import/export matters most when a request needs to travel outside the tool — a curl command from a teammate’s Slack message, an API provider’s documentation example, or a request you want to paste into a bug report or script. Pasting one in should reconstruct the whole request; exporting one should reproduce it exactly.