HTTP Status Codes Cheat Sheet for Testers (2026)

HTTP Status Codes Cheat Sheet for Testers 

Every API response starts with a three-digit status code that tells you what happened. Checking the right code — not just "any 2xx" — is the first assertion in almost every API test.

This cheat sheet covers the HTTP status codes testers actually validate, what each one means, which codes to expect for common operations, and how to assert them in Postman and REST Assured.

The Five Families

Tester's rule of thumb: A bad request from the client should generally receive a 4xx response. A 5xx response for invalid input can indicate a server-side validation defect — the server should handle invalid input rather than crash.

2xx — Success

200 OK

A 200 response indicates that the request was successfully processed.

Example:

GET /users/42
HTTP/1.1 200 OK

The response normally contains the requested resource or result.

201 Created

A 201 response indicates that a new resource was successfully created.

A typical response may include:

HTTP/1.1 201 Created
Location: /users/101

202 Accepted

202 Accepted means the request has been accepted for processing but the processing may not have completed yet.

This is useful for asynchronous operations such as:

• Report generation
• Large file processing
• Background jobs
• Batch operations

204 No Content

204 indicates successful processing with no response body.

A common example is:

DELETE /users/101
HTTP/1.1 204 No Content

3xx — Redirection

Most HTTP clients, including Postman and many REST Assured configurations, can follow redirects automatically.

If you need to assert the original 3xx response itself, disable automatic redirect handling.

4xx — Client Errors ⭐

These are some of the most important codes for API testers, particularly during negative testing.

400 Bad Request

Use 400 when the request itself is invalid or malformed.

Examples:

• Invalid JSON
• Incorrect JSON structure
• Wrong data types
• Missing required request information

Example:

{
  "name": 12345,
  "email": "invalid"
}

Depending on the API's contract, such input could result in a 400 response.

401 Unauthorized

401 generally indicates an authentication problem.

Common scenarios:

• No access token
• Invalid token
• Expired token
• Invalid authentication credentials

403 Forbidden

403 means the server understands who the caller is but the caller is not permitted to perform the requested action.

For example:

Authenticated user → Yes
Permission required → Admin
User role → Regular User
Result → 403 Forbidden

404 Not Found

404 indicates that the requested resource or endpoint cannot be found.

Example:

GET /users/999999
HTTP/1.1 404 Not Found

405 Method Not Allowed

The endpoint exists, but the HTTP method is not supported for that resource.

For example:

DELETE /reports/2026

could return 405 if the endpoint supports only GET.

409 Conflict

409 is useful when the request conflicts with the current state of a resource.

A common example is attempting to create a user with an email address that already exists.

415 Unsupported Media Type

This can occur when the client sends an unsupported Content-Type.

For example, an API expecting:

Content-Type: application/json

might reject an unsupported media type.

422 Unprocessable Content

A 422 response can be used when the request is syntactically valid but violates application-level validation rules.

Example:

{
  "startDate": "2026-10-20",
  "endDate": "2026-10-10"
}

The JSON is valid, but the business rule may require the end date to be after the start date.

429 Too Many Requests

429 indicates that the client has exceeded a rate limit.

The response may include a:

Retry-After

header telling the client when it can try again.

5xx — Server Errors

500 Internal Server Error

A 500 usually indicates an unexpected server-side failure.

For example:

Client sends valid request
        ↓
Server processes request
        ↓
Unhandled exception
        ↓
500 Internal Server Error

As a tester, investigate the request, response, server logs and reproducibility.

502 Bad Gateway

A 502 commonly occurs when a gateway, load balancer or proxy receives an invalid response from an upstream service.

503 Service Unavailable

A 503 indicates that the service is temporarily unavailable.

Possible causes include:

• Maintenance
• Deployment
• Temporary overload
• Service dependency unavailable

504 Gateway Timeout

A 504 indicates that a gateway or proxy did not receive a response from an upstream service within the expected time.

Expected Status Code by Operation

APIs do not always follow generic conventions. The API documentation, OpenAPI specification or Swagger documentation is the source of truth.

If the API contract explicitly specifies 200 but the implementation returns 201, investigate whether the implementation or documentation is incorrect.

More:

• HTTP Methods & Status Codes
• GET vs POST vs PUT vs PATCH

Asserting Status Codes in Code

Postman — Tests Tab

// Create user — expect 201 and a new id
pm.test('201 Created', () => pm.response.to.have.status(201));

pm.test('Returns the new id', () => {
    pm.expect(pm.response.json().id).to.be.a('number');
});

// Same request without a token — expect 401
pm.test('401 without a token', () => {
    pm.response.to.have.status(401);
});

// Missing resource — expect 404
pm.test('404 for a missing user', () => {
    pm.response.to.have.status(404);
});

These tests were run with Newman against a local API, with all tests passing.

REST Assured

given()
    .header("Authorization", "Bearer " + token)
    .contentType(ContentType.JSON)
    .body(newUser)
.when()
    .post("/users")
.then()
    .statusCode(201);

given()
    .contentType(ContentType.JSON)
    .body(newUser)   // no token
.when()
    .post("/users")
.then()
    .statusCode(401);

when()
    .get("/users/999")
.then()
    .statusCode(404);

You can also check for any successful 2xx response:

when()
    .get("/users/101")
.then()
    .statusCode(
        allOf(
            greaterThanOrEqualTo(200),
            lessThan(300)
        )
    );

However, use broad 2xx assertions sparingly.

If the API contract says a successful POST should return 201, asserting only that the response is somewhere in the 2xx range could allow an incorrect 200 response to pass.

Exact status-code assertions catch more bugs.

Always pair status-code validation with additional checks such as:

• Response body
• Response schema
• Headers
• Response time
• Database or application side effects
• Business rules

A 200 response containing an error message in the body can still represent a defect.

Design full negative-test sets for real endpoints in the API Testing Scenario Lab.

Common Interview Questions ⭐

401 Unauthorized vs 403 Forbidden?

401 generally means authentication is missing, invalid or expired. The server cannot successfully authenticate the request.

403 means the request is understood and authenticated, but the caller does not have permission to perform the requested action.

Easy way to remember:

401 = Who are you?

403 = I know who you are, but you're not allowed.

500 vs 503?

500 indicates an unexpected server-side failure.

503 indicates that the service is temporarily unavailable, such as during maintenance, deployment or temporary overload.

201 vs 204?

201 means a new resource was created.

204 means the request succeeded but the response contains no body.

400 vs 422?

400 is commonly used when the request itself is malformed or invalid.

422 can be used when the request is syntactically valid but fails application or business validation.

The exact choice depends on the API contract.

From Real Projects

I've worked with APIs at the level this page covers: CRUD operations, HTTP methods, JSON and XML formats, and extracting and validating values with JSON path. A good habit from that work: test the full create–read–update–delete cycle for a resource and check each response in detail. Testsigma supports web, mobile and API test automation, so understanding APIs was part of understanding the product I was testing. Check the status code and the response body together; a 200 can still carry the wrong data.

📚 Official documentation: MDN: HTTP

Frequently Asked Questions

Which status codes should every API tester know?

At minimum, understand:

200, 201, 204, 400, 401, 403, 404, 405, 409, 415, 422, 429, 500, 502, 503 and 504.

You should also understand the broader 1xx, 2xx, 3xx, 4xx and 5xx categories.

Should a validation error return 400 or 500?

A validation error should generally result in a 4xx response, commonly 400 or 422, depending on the API contract.

A 500 response for invalid client input can indicate that the server failed to handle the invalid request correctly.

Is it enough to check the status code?

No.

A complete API test should also consider:

• Response body
• Schema
• Headers
• Authentication
• Business rules
• Response time
• Database or other side effects

For example, an API could return 200 while putting an error message inside the response body.

What status code should DELETE return?

A successful DELETE commonly returns:

• 204 when there is no response body
• 200 when the API returns a response body

The exact behaviour should follow the API contract.

A second DELETE against a resource that no longer exists may return 404, although idempotency and API design can influence the chosen response.

Why does my test get 200 when the API returns a redirect?

Postman and many HTTP clients follow redirects automatically.

If you need to test the original redirect response, disable automatic redirect following and assert the 3xx response directly.

Go Deeper

• The Complete API Testing Tutorial
• HTTP Requests & Responses
• Negative Testing & Error Handling with REST Assured
• Top 30 API Testing Interview Questions