API Testing Interview Questions

I go way beyond happy paths. A solid API strategy covers negative cases, contract validation, auth security, data integrity, response semantics, and operational limits like rate controls and latency. The goal isn't checking every endpoint — it's systematically covering the behaviors that matter.

Contract tests verify that requests and responses match the agreed interface. Integration tests check how your service talks to real dependencies. End-to-end API tests validate complete workflows across multiple services. They're layers of confidence, not replacements for each other.

HTTP methods have semantics that should guide your tests. GET should be safe and repeatable. PUT and DELETE should be idempotent — doing them twice shouldn't break anything. POST creates new state, so duplicates matter. Design your tests around these expectations, not just status codes.

Status code is the headline, not the story. I validate headers, payload shape, field semantics, error structure, schema conformance, and sometimes timing. A 200 with the wrong data is worse than a 400 with a clear error.

I test the full auth lifecycle: valid credentials, invalid credentials, expired tokens, malformed tokens, role boundaries, and object-level access control. The OWASP top API risks are broken authentication and broken object-level authorization — so I treat these as first-class test scenarios, not afterthoughts.

OpenAPI is a living contract, not a static document. I use it to validate request/response schemas, auto-generate tests, detect breaking changes in CI, and discover missing edge cases. But it only works if the spec stays current with the code.

I create data through APIs or controlled fixtures, not by manually seeding databases. Every test should own its data, clean up after itself, and use unique identifiers to avoid collisions in parallel runs. If data setup is hard, that's an architecture smell, not a test problem.

Mock when the dependency is unstable, slow, expensive, or outside the scope of what you're testing. But always keep a smaller layer of real integration checks to catch contract drift. Don't let your test suite become a fantasy version of your system.

These are operational correctness issues, not just functional ones. I test page boundaries, sort stability, filter accuracy, and what happens at the edges — empty pages, last pages, rate limit thresholds, and retry exhaustion. Real APIs live in the real world; your tests should too.

I collect everything before I guess: request/response bodies, headers, correlation IDs, timing, schema diffs, and environment context. Then I classify the failure — contract drift, auth issue, data collision, dependency noise, or infrastructure timing. Good debugging is methodical, not magical.