HTTP Status Codes Every Tester Should Know (and How to Test Them)

Every API bug report starts with a status code, and a surprising number of API bugs are status codes — the right behavior wearing the wrong number. Knowing what each code promises lets you spot those bugs instantly, and it makes your reports far more convincing: "returns 200 with an error body" is a much sharper finding than "login seems broken".

The codes you'll meet every day

• 200 OK / 201 Created / 204 No Content — success, but not interchangeable. A create endpoint answering 200 instead of 201, or a delete returning 200 with an empty body instead of 204, is worth a ticket.
• 400 Bad Request — the client sent something malformed. The body should say what was wrong; a bare 400 is a usability bug for API consumers.
• 401 vs 403 — the most-confused pair. 401 means "we don't know who you are" (missing or invalid credentials); 403 means "we know who you are, and you're not allowed". If an expired token gives 403, or a permissions failure gives 401, flag it.
• 404 vs 400 — a missing resource is 404; a syntactically invalid ID is arguably 400. Whatever the team decides, it should be consistent across endpoints.
• 409 Conflict / 422 Unprocessable Entity — the request was well-formed but the state or semantics reject it: duplicate emails, versions that moved on, business-rule failures.
• 429 Too Many Requests — check for a Retry-After header. Rate limiting without it makes clients guess.
• 500 vs 502/503/504 — 500 is the app itself crashing; 502/503/504 usually point at the infrastructure in front of it. Knowing the difference tells you which team to ping.

When you hit a code you don't recognize mid-session, the HTTP Status Code Reference gives you a searchable, plain-English reference — no digging through RFCs while a meeting waits.

Turning codes into test cases

A quick heuristic: for every endpoint, ask what should produce each of 200/201, 400, 401, 403, 404 and 409 — and then actually send those requests. The API Test Checklist walks through exactly this kind of coverage, from happy paths to auth, validation and edge cases, and remembers your progress as you go.

Building the bad requests is half the work. Use the Query Parameter Builder to construct URLs with deliberately awkward, properly-encoded parameter values, and the URL Parser to pull apart a URL from a bug report and see exactly which parameter decodes to what.

Sharing a reproduction

When you find the bug, hand the developer a copy-pasteable repro. Paste the one-line cURL from your terminal or browser dev tools into the cURL Formatter and you get a readable, multi-line command with the method, headers and body clearly visible — the kind of repro that gets fixed the same day.