Assert the exact status the contract promises, not just 'is 2xx'. 201 for creation (with Location), 204 for no body, 401 when you are not authenticated, 403 when you are authenticated but not allowed, 400 for malformed input, 422 for well-formed but invalid input, 409 for conflicts, 5xx is always a bug.
Full answer with examplesInterview questions / API
API Testing Interview Questions
HTTP semantics, status codes, idempotency, auth and contract thinking: the API questions that separate testers who call endpoints from testers who design API test strategy.
7 questions · 3 beginner· 2 intermediate· 2 advanced
beginner questions
PUT vs PATCH (and POST), and what does idempotency mean?
beginner 0–2 yrs
PUT replaces the whole resource at a known URI and is idempotent; PATCH applies a partial change and is not guaranteed idempotent; POST creates or triggers actions and is not idempotent. Idempotent means repeating the same request leaves the server in the same state as sending it once.
Full answer with examplesWhat do you validate in an API response beyond the status code?
beginner 0–2 yrs
Check the status, then headers (Content-Type, caching, Location), the body's schema (types, required fields), the actual values against the request and business rules, error formats for negative cases, response time, and side effects such as the database or a follow-up GET.
Full answer with examplesintermediate questions
How do you test pagination?
intermediate 2–5 yrs
Know the style first (offset/limit or cursor). Then test page size defaults and limits, first/last/empty pages, invalid parameters, metadata and links, no duplicates or gaps when walking all pages, stable ordering with ties, and what happens when data changes between page requests.
Full answer with examplesHow do you test API authentication and authorization (OAuth 2.0, JWT)?
intermediate 2–5 yrs
Test authentication (missing, malformed, expired, wrongly signed tokens give 401) separately from authorization (each role and scope only reaches what it should, 403 or 404 otherwise). For JWTs, check signature, exp, audience and alg handling; for OAuth, test token acquisition, scopes, refresh and revocation.
Full answer with examplesadvanced questions
Consumers record the interactions they actually rely on as contracts (for example with Pact); the provider replays them against its real code. Schema validation only checks a response matches a spec. Contracts catch breaking changes for real consumers before deploy, without a shared end-to-end environment.
Full answer with examplesFor rate limits, send a controlled burst and assert 429 with Retry-After at the documented threshold, per key, then recovery after the window. For concurrency, fire truly parallel requests at shared state (stock, balances, unique fields) and assert invariants, optimistic locking (409/412) and idempotency keys.
Full answer with examplesWhat API testing interviews look for
Calling an endpoint and checking for 200 is the starting point, not the answer. Interviewers want to hear that you understand HTTP semantics well enough to design tests from them. At junior level that means methods, status codes and what to check in a response. At mid level it means authentication versus authorisation, pagination, error formats and test data. Senior candidates are expected to discuss concurrency, rate limiting, idempotency under retries and how contract testing fits alongside end-to-end tests.
Concepts to study first
- Status codes that matter: 401 means "who are you?" and 403 means "I know who you are, and no"; 400 is a malformed request while 422 is a well-formed request that fails validation; 201 should come with the created resource or a
Locationheader. - PUT vs PATCH and idempotency: PUT replaces and is idempotent; PATCH applies a partial change and may or may not be; POST is neither safe nor idempotent, which is why payment APIs use idempotency keys.
- What to validate beyond the status code: headers, schema, business rules, side effects in other systems and response time.
- Auth testing with OAuth 2.0 and JWT: expired, tampered and wrong-audience tokens, and object-level authorisation (can user A read user B's order?).
A worked answer: testing pagination
For "how do you test pagination?", structure the answer by risk. Check the boundaries: first page, last page, an empty result, a page beyond the end and invalid page sizes (0, negative, above the maximum). Check consistency: walking every page returns each record exactly once, and the total in X-Total-Count or the response body matches. Then check stability: what happens if a record is inserted while a client is paging? Offset pagination can skip or repeat items, which is a common real defect and a reason APIs move to cursor-based pagination. The model answer for testing pagination includes example assertions.
Contracts, concurrency and rate limits
Senior API testing interview questions often go beyond a single endpoint. Consumer-driven contract testing, usually with Pact, lets a consumer publish the requests it makes and the response fields it relies on, and the provider verifies against those contracts in its own pipeline. It catches breaking changes earlier than end-to-end tests and is narrower than schema validation, which checks the whole document shape but not what any consumer actually uses.
For rate limiting and concurrency, describe firing parallel requests to check that limits return 429 with a Retry-After header, and that two simultaneous updates to the same resource cannot both succeed when they should conflict.
Practise with real requests
The API testing playground sends real requests to a practice API with validation errors, bearer-token auth, pagination headers and RFC 9457 problem responses, and its exercises check the responses you actually get. To practise automation, the Playwright lab has graded API contract challenges for the cart API and login and profile. Related topics: Postman and REST Assured interview questions.