Practical QA guide · 13 min
API Testing Guide
Learn a practical approach to API testing across contracts, status codes, validation, authentication, data integrity, negative cases, idempotency, and integration behavior.
Written and reviewed by ShiftQA Labs QA Education Team · Updated October 6, 2026
Browse Lessons modules
Test the contract and the business rule
A 200 response is not enough. Verify required and optional fields, data types, identifiers, relationships, and whether the returned state matches the business operation that was requested.
Use the API specification as one source of expectation, then validate domain rules that may not be fully expressed by the schema: eligibility, ownership, limits, transitions, pricing, or permissions.
Design negative and authorization coverage
Exercise missing fields, malformed values, unsupported values, boundary conditions, expired tokens, wrong roles, and attempts to access another user's resources. The expected result includes both the response and the absence of an unsafe side effect.
Authorization tests should distinguish authentication from ownership. A request can come from a valid signed-in user and still be forbidden from reading or changing a particular resource.
Check retries, consistency, and integrations
For operations that may be retried, determine whether idempotency is required. Repeating a payment, order, invite, or webhook should not create duplicate effects when the contract promises safe retries.
Where an API triggers asynchronous work, test the accepted request, resulting state transitions, eventual output, and failure recovery separately. Do not mark the operation successful only because the initial endpoint accepted the request.
Worked example
Testing POST /orders
An authenticated customer creates an order from a valid cart.
- 1Send a valid request and verify the expected created status, schema, customer ownership, amount, and persistent order record.
- 2Repeat the same idempotency key and verify a duplicate order is not created.
- 3Remove a required field and verify a validation response with no order created.
- 4Use another customer's cart identifier and verify the request is forbidden without exposing private cart data.
- 5Simulate an unavailable downstream payment or inventory dependency and verify the order reaches the documented recoverable state rather than a false success.
Frequently asked questions
Questions testers ask
What is the difference between API testing and integration testing?
API testing focuses on the exposed interface and its behavior. Integration testing is broader and evaluates how multiple components or services work together. One API test can also be an integration test depending on scope.
Should API tests verify the database directly?
Sometimes. Direct database checks can provide strong evidence for persistent side effects, but they couple tests to implementation. Prefer observable contracts unless internal verification is necessary for the risk being tested.
What should I test besides status codes?
Response schema, business rules, permissions, data integrity, side effects, error contracts, performance expectations, idempotency, and downstream behavior are often more important than the status code alone.