The Complete API Testing Masterclass: Status Codes, Strategies, and Frameworks for Every QA Engineer
Contents
The HTTP Status Code Post That Got 60,000 Impressions
Sumit Goyal, a QA educator with over 60,000 LinkedIn followers, posted a simple visual guide to HTTP status codes that was reposted across multiple QA communities. The engagement revealed something important: despite API testing being a core QA skill, many testers still struggle with the fundamentals — particularly understanding which status codes indicate bugs vs. expected behavior.
This guide covers everything a QA engineer needs to know about API testing — from memorizing status codes to building a complete API testing framework integrated with CI/CD.
HTTP Status Codes: The Complete Reference for Testers
1xx (Informational): The server received your request and is processing it. 100 Continue means the server received the headers and the client should proceed with the body. 101 Switching Protocols means the server is changing protocols per the client’s request. These rarely appear in API testing but understanding them helps when debugging WebSocket connections.
2xx (Success): The request was successfully received, understood, and accepted. 200 OK is the standard success response. 201 Created means a new resource was created (common in POST requests). 204 No Content means success but no response body (common for DELETE operations). As a tester, every 2xx response should trigger validation: did the server actually do what you asked?
3xx (Redirection): The client must take additional action to complete the request. 301 Moved Permanently and 302 Found are the most common. 304 Not Modified means the cached version is still valid. Test redirects explicitly — many bugs hide in redirect chains, especially with authentication flows.
4xx (Client Errors): The request contains bad syntax or cannot be fulfilled. 400 Bad Request means malformed input. 401 Unauthorized means authentication is required. 403 Forbidden means you are authenticated but not authorized. 404 Not Found means the resource does not exist. 422 Unprocessable Entity means the request was well-formed but semantically incorrect. Every API endpoint should have thorough 4xx testing — this is where most input validation bugs live.
5xx (Server Errors): The server failed to fulfill a valid request. 500 Internal Server Error is the generic catch-all. 502 Bad Gateway means the upstream server returned an invalid response. 503 Service Unavailable means the server is temporarily overloaded. Any 5xx response in testing is a potential bug — the API should handle errors gracefully and return appropriate 4xx codes instead of crashing.
REST API Testing Strategies
Positive testing: Verify that the API returns correct responses for valid inputs. Send well-formed requests with valid authentication, valid data types, and expected values. Validate response status codes, response body structure, data accuracy, and response headers.
Negative testing: Verify that the API handles invalid inputs gracefully. Send requests with missing required fields, invalid data types, exceeded length limits, SQL injection payloads, and XSS strings. The API should return appropriate 4xx errors with helpful error messages — never 5xx errors.
Boundary testing: Test the edges of input ranges. If a field accepts 1-100 characters, test with 0, 1, 100, and 101. If a numeric field accepts 0-999, test with -1, 0, 999, and 1000. Boundary bugs are among the most common API defects.
Security testing: Verify authentication (valid/invalid/expired tokens), authorization (accessing resources you should not have access to), rate limiting (sending more requests than allowed), and input sanitization (injection attacks). Security is not optional for API testing — it is a core responsibility.
Performance testing: Measure response times under normal and peak load. Verify that the API meets SLA requirements. Test concurrent request handling. Identify bottlenecks in specific endpoints. Tools like k6, JMeter, and Artillery are purpose-built for this.
API Contract Testing with Pact
In microservices architectures, API contract testing ensures that services can communicate correctly without requiring full integration tests. Pact is the industry standard for consumer-driven contract testing. The consumer defines the expected API behavior (the contract), the provider verifies that it meets the contract, and if either side changes in a way that breaks the contract, tests fail immediately — before deployment.
Contract testing catches integration bugs that unit tests miss and end-to-end tests catch too late. It is particularly valuable when multiple teams own different services and cannot always coordinate deployments.
Frequently Asked Questions
What is the best tool for API testing in 2026?
There is no single best tool — it depends on your stack and needs. Postman is excellent for manual exploration and quick tests. Playwright’s API testing capabilities are ideal if you are already using Playwright for E2E testing. RestAssured (Java) and Supertest (JavaScript) are strong for programmatic testing. Karate provides a no-code approach with powerful assertion capabilities. Start with whatever integrates best with your existing framework.
Should I validate JSON schema in every API test?
Yes, but efficiently. Use JSON Schema validation as a baseline assertion that runs against every API response. This catches structural changes (missing fields, wrong data types, unexpected nulls) automatically without writing field-by-field assertions for every test. Libraries like ajv (JavaScript) and jsonschema (Python) make this straightforward.
