API Testing interview questions
API Testing questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
An API returns 200 with an error object in the body. What do you report?
The strongest answer: The contract mismatch: status, body, and what the client does with it — “200 + error” is a bug if the spec said 4xx, or a spec bug if it is intentional and undocumented
Why it works: Exactly. Status and body together are the contract. QA can say when they disagree.
- Read status and body.
- Compare to the spec.
- Say what the client will do.
- Do not “fix” it in the assertion.
What do GET, POST, PUT, PATCH and DELETE tell you before you write a single API test?
The strongest answer: What each one promises: GET reads without changing anything, POST creates, PUT replaces, PATCH changes part, DELETE removes — so my first tests check each keeps its promise
Why it works: Exactly — the method is a contract, and a GET that changes data or a DELETE that quietly does nothing is a real defect.
- The method is a promise.
- GET reads; POST creates.
- PUT replaces; PATCH updates part.
- Test that each promise holds.
An endpoint returns 400 for one request and 500 for another. What does that difference tell you?
The strongest answer: 4xx says the request was wrong, so my data or the client is at fault; 5xx says the server broke while handling it, which is a defect even when my input was nonsense
Why it works: Right — and the corollary matters: a server that answers bad input with a 500 is still a bug, because it should reject it as 4xx.
- 4xx is yours; 5xx is theirs.
- On 4xx, check what you sent.
- On 5xx, get the server logs.
- Bad input should never be a 500.
The UI looks fine; the list API dropped a field the mobile app still needs. Who should have caught it?
The strongest answer: A contract test or a schema check on the API — I do not wait for a pixel to move — and I can describe that without writing the code in this room
Why it works: Exactly. Contract / schema is QA’s friend. You can talk it without pairing on the HTTP client.
- Check the contract, not only the pixels.
- Schema / example / status.
- You do not need to write the client here.
- Do not wait for prod.
Which request and response headers do you actually look at when testing an API?
The strongest answer: Content-Type on both sides, Authorization on protected calls, and whatever the API uses for caching, correlation ids and rate limits — a wrong Content-Type alone explains a lot of 4xx responses
Why it works: Exactly — headers carry the content negotiation, the identity, and the correlation id you will want when you file the bug.
- Headers are part of the request.
- Check Content-Type both ways.
- Check Authorization on protected calls.
- Keep the correlation id for bugs.
Pay is a POST. What conceptual API check do you insist on?
The strongest answer: What happens on a retry: a second charge, a 409, an idempotency key — I describe the behaviour I want, I do not write the client in the room
Why it works: Exactly. Idempotency is a QA question. You can ask it without pairing on the code.
- Ask what a retry does.
- Look for an idempotency story.
- Do not trust “500 = no charge.”
- API and UI both, conceptually.
Two clients consume one API. Where do you put the cheapest tests?
The strongest answer: On the contract — examples, status, required fields — before either UI, so both clients inherit the oracle
Why it works: Exactly. One contract, two clients. That is shift-left you can fund.
- Contract first.
- Share the examples.
- UI tests still walk a path.
- Do not wait for prod probes.
You are asked to “test the API” and you will not write a framework in the room. What do you still cover?
The strongest answer: Authn / authz, happy and refused, idempotency, pagination / empty, and the error shape — conceptually, with examples, not a lecture on a language
Why it works: Exactly. Those behaviours are the API product. You can score them without pairing on code.
- Authn and authz.
- Retry and empty.
- Error shape.
- Examples, not a framework demo.
The OpenAPI file is stale. Tests use a different example. What do you do?
The strongest answer: I make one example the source — generate or fail CI when they drift — I do not keep three truths
Why it works: Exactly. One source, CI when they drift. Three truths are how mobile and web disagree.
- One example source.
- CI on drift.
- Keep a readable contract.
- Do not trust review alone.
You are asked to test authentication and authorisation on an API. What is on your list?
The strongest answer: No token, an expired token and a tampered one all rejected; user A’s token refused on user B’s records; a low-privilege user refused on an admin endpoint — with 401 and 403 used as intended
Why it works: Exactly — expiry, tampering, another user’s data and privilege level are the four that actually catch defects.
- Test refusal, not only access.
- No token, expired, tampered.
- Another user’s records.
- Lower privilege on admin routes.
Mobile, web, and a partner all break when you add a field. What quality object were you missing?
The strongest answer: The API as a product: compatibility, examples, and a deprecation story — not “a backend detail”
Why it works: Exactly. Compatibility is a product. Clients should not be your only sensor.
- Treat the API as a product.
- Compatibility tests / examples.
- A deprecation story.
- Do not rely on client pixels only.