?? Master API Testing with HTTP Status Codes!
Vijo Varghese
??? Engineering Excellence in QA & Project Management | ?? Supercharging Teams with AI Magic
APIs power the digital world, but what happens when they fail? A single unhandled error can break an app, frustrate users, and even expose security risks!
As QA engineers, it’s our job to hunt down these API failures before they hit production. But are we catching all the critical edge cases? ??
Correct HTTP status codes are crucial for ensuring reliability and accuracy. Here’s a quick breakdown to level up your API validation skills!
HTTP Status Code Guide for API Testing
?? 1xx – Informational (Processing in progress)
?? 100 Continue – Server received request headers, client should continue.
? 102 Processing – The Server is working on the request, but it’s taking time.
?? 2xx – Success (Everything worked as expected)
? 200 OK – Successful request (GET, PUT, PATCH).
?? 201 Created – Resource successfully created (POST).
?? 202 Accepted – Request accepted for processing but not completed yet.
?? 204 No Content – Request processed, but no response body (DELETE).
?? 3xx – Redirection (Further action is needed)
?? 301 Moved Permanently – Resource moved to a new URL.
? 302 Found (Temporary Redirect) – Requested resource is temporarily at another URL.
?? 304 Not Modified – Cached version of the resource is still valid.
?? 4xx – Client Errors (The request is incorrect or missing something!)
?? 400 Bad Request – Malformed request, missing parameters, or incorrect format.
?? 401 Unauthorized – Missing or invalid authentication credentials.
?? 403 Forbidden – Authentication is valid, but the user is not authorized.
?? 404 Not Found – The requested resource doesn’t exist.
?? 405 Method Not Allowed – Request method (GET, POST, etc.) is not supported.
? 408 Request Timeout – The client took too long to send a request.
?? 409 Conflict – The request conflicts with the current server state (e.g., duplicate data).
?? 413 Payload Too Large – Request body is too large to process.
?? 415 Unsupported Media Type – The Server doesn’t support the request format.
?? 422 Unprocessable Entity – Request is valid but contains logical errors (e.g., invalid email format).
?? 429 Too Many Requests – Client is being rate-limited for sending too many requests.
?? 5xx – Server Errors (Something went wrong on the server!)
?? 500 Internal Server Error – Generic error; the server failed to process the request.
?? 502 Bad Gateway – The Server received an invalid response from an upstream server.
? 503 Service Unavailable – Server is down for maintenance or overloaded.
? 504 Gateway Timeout – Gateway or Proxy did not get a response in time from the upstream server to complete the request an upstream server.
?? 507 Insufficient Storage – The Server ran out of space to process the request.
?? API Error Scenarios for QA Testing
Beyond the basics, here are additional real-world error scenarios you should test as a QA. Ensuring APIs handle these properly can prevent production failures and improve user experience!
1?? Authentication & Authorization Errors
?? Scenario: The User tries to refresh an expired token.
?? Expected: 401 Unauthorized
?? QA Action: Ensure the API provides a clear message guiding the user to re-authenticate.
?? Scenario: The User provides a token with incorrect formatting.
?? Expected: 400 Bad Request
?? QA Action: Test invalid token structures like empty tokens, malformed JWTs, or missing headers.
?? Scenario: The User tries to act as email verification.
?? Expected: 403 Forbidden
?? QA Action: API should block actions requiring verification and return a clear error.
2?? Input Validation & Request Errors
?? Scenario: The User submits a password that is too short.
?? Expected: 422 Unprocessable Entity
?? QA Action: Validate API enforces security rules like minimum length, special characters, etc.
?? Scenario: The User enters an unsupported date format.
?? Expected: 400 Bad Request
?? QA Action: Test various date formats, including invalid ones like "32-13-2025".
?? Scenario: The User submits a negative value where only positive values are allowed.
?? Expected: 422 Unprocessable Entity
?? QA Action: Ensure the API prevents illogical inputs (e.g., negative age or price).
?? Scenario: API expects a list, but a string is sent.
?? Expected: 400 Bad Request
?? QA Action: Test different data types (e.g., passing a string where an array is expected).
?? Scenario: User sends a request with an excessive payload (e.g., 10MB JSON).
?? Expected: 413 Payload Too Large
?? QA Action: Ensure API rejects large payloads gracefully without crashing.
?? Scenario: The User tries to use an HTTP method that is not allowed (e.g., DELETE on a read-only resource).
?? Expected: 405 Method Not Allowed
?? QA Action: Ensure the API properly restricts actions based on the request method.
3?? Resource Handling & Data Integrity
?? Scenario: The User tries to update a record that doesn’t exist.
?? Expected: 404 Not Found
?? QA Action: Validate that the API correctly distinguishes between missing and existing resources.
?? Scenario: User deletes item, then tries to access it.
?? Expected: 404 Not Found
?? QA Action: Ensure deletion is permanent and API correctly handles cache refreshes.
?? Scenario: Two users try to edit the same resource simultaneously.
?? Expected: 409 Conflict
?? QA Action: Check if the API supports optimistic locking or version control to prevent overwrites.
?? Scenario: The User submits a duplicate entry that must be unique (e.g., same email).
?? Expected: 409 Conflict
?? QA Action: Ensure the API enforces unique constraints and returns a clear error message.
?? Scenario: The User tries to delete a resource that is referenced elsewhere (e.g., deleting a category still linked to products).
?? Expected: 400 Bad Request or 409 Conflict ?? QA Action: Verify that dependencies are checked before deletion and that the error message provides guidance.
4?? Rate Limiting & Performance Issues
?? Scenario: User rapidly sends requests in a short time frame.
?? Expected: 429 Too Many Requests
?? QA Action: Test API rate limiting with automated scripts to check throttling behavior.
?? Scenario: API is under heavy load and takes too long to respond.
?? Expected: 504 Gateway Timeout
?? QA Action: Monitor API response times and test graceful degradation under stress.
?? Scenario: The database is unavailable when the API tries to fetch data.
?? Expected: 500 Internal Server Error
?? QA Action: Ensure the API handles database failures properly and returns a helpful error.
?? Scenario: API requests take significantly longer due to large data processing.
?? Expected: 202 Accepted (for async processing) instead of blocking the request.
?? QA Action: Validate that the API supports background processing or pagination to avoid timeouts.
5?? Security & Injection Attacks
?? Scenario: User submits SQL-like input (DROP TABLE users;).
?? Expected: 400 Bad Request (if sanitized) or 500 Internal Server Error (if the API is vulnerable).
?? QA Action: Ensure API prevents SQL Injection attacks through proper input validation & sanitization.
?? Scenario: The User enters script tags in a text field (<script>alert('XSS')</script>).
?? Expected: 400 Bad Request
?? QA Action: Verify that API escapes or rejects XSS payloads to prevent Cross-Site Scripting (XSS) attacks.
?? Scenario: The User tries to bypass authentication using a forged token.
?? Expected: 401 Unauthorized
?? QA Action: Ensure API verifies JWT signatures and detects expired tokens correctly.
?? Scenario: User attempts brute-force login attempts.
?? Expected: 429 Too Many Requests
?? QA Action: Test if the API implements lockout mechanisms after repeated failed logins.
?? Scenario: An API accidentally exposes sensitive data in error messages.
?? Expected: Properly masked or generic error message.
?? QA Action: Ensure the API never leaks internal stack traces, database details, or user data.
?? Final Thoughts: How QA Should Handle API Errors
? Test all possible failure scenarios—don’t just focus on the happy path!
? Check the response body—error messages should be clear and helpful.
? Test different user roles—ensure API correctly enforces permissions.
? Monitor response times—slow APIs can ruin user experience.
? Use automation—simulate edge cases using Postman, JMeter, or Cypress.
?? Pro Tip: Run tests with random, extreme, and unexpected inputs to catch failures!
?? Which API errors have you encountered the most?
?? Drop them in the comments!
Lead Engineer at QBurst
3 天å‰Good intro for developers