Which HTTP status codes matter in API testing? 401 vs 403, 400 vs 422, 200 vs 201 vs 204

Status codes are the first thing a client branches on, so a wrong code is a real defect even when the body looks fine. A mobile app that retries on 5xx but not 4xx will behave very differently if the server returns 500 for a validation error.

The classes

• 2xx: the request succeeded.
• 3xx: redirection; rare in JSON APIs except for 304 Not Modified with caching.
• 4xx: the client did something wrong. Retrying the same request will not help.
• 5xx: the server failed. These should never be the result of user input.

The pairs interviewers ask about

200 vs 201 vs 204

• 200 OK: generic success with a body (GET, or an update that returns the resource).
• 201 Created: a POST created a resource. Good APIs also return a Location header pointing to it.
• 204 No Content: success with an empty body, typical for DELETE or a PUT that returns nothing. Assert the body really is empty.

401 vs 403

• 401 Unauthorized actually means unauthenticated: no token, an expired token or an invalid signature. It should include a WWW-Authenticate header.
• 403 Forbidden means the server knows who you are and you are not allowed to do this, for example a regular user calling an admin endpoint.

Some APIs deliberately return 404 instead of 403 for resources you do not own, so they do not leak that the resource exists. That is a valid design, but it must be consistent and documented.

400 vs 422

• 400 Bad Request: the request cannot be parsed or is structurally wrong: invalid JSON, wrong content type, missing required field.
• 422 Unprocessable Content: the JSON is fine but the values break business rules, such as an end date before the start date.

Many APIs use 400 for both. What matters is that the team picks one convention and you test against it.

Others worth knowing

• 404 for unknown resources, 405 for an unsupported method, 409 Conflict for duplicates or version conflicts, 412 for a failed If-Match precondition, 415 for an unsupported media type, 429 Too Many Requests for rate limiting (often with Retry-After).

How I test it

given()
    .contentType(ContentType.JSON)
    .body("{\"email\": \"not-an-email\"}")
.when()
    .post("/users")
.then()
    .statusCode(400)
    .body("errors[0].field", equalTo("email"));

For each endpoint I build a small matrix: happy path, missing auth (401), wrong role (403), unknown id (404), malformed body (400), rule violation (422 or 400), duplicate (409). Any 500 in that matrix is a bug, because the server failed to validate input.

What interviewers look for

• Correct meaning of 401 vs 403, including that 401 really means unauthenticated.
• Asserting exact codes from the contract rather than “any 2xx”.
• Treating 5xx caused by client input as a defect.
• Awareness that status alone is not enough; the error body and headers matter too.

Common mistakes

• Asserting statusCode(lessThan(300)) and missing that a create returned 200 without creating anything.
• Assuming 404 for someone else’s resource is wrong without checking the API’s security convention.