API testing interview questions

API testing checks the service layer directly — you send a request and assert on the response, without a browser. You verify status, body, headers and behaviour where the logic actually lives.

You test here because it's faster, more stable and closer to the bug than the UI. A broken business rule shows up in the API response long before it surfaces as a mislabelled button, and an API test doesn't flake on a slow render.

A unit test checks one function in isolation, usually with everything around it mocked — it proves the code unit is correct. An API test hits a running service over HTTP and checks the whole request-to-response path: routing, serialisation, auth, the database, the lot.

Unit tests are the developer's; API tests are often yours. They overlap in intent but not in scope — a passing unit test says the function works; a passing API test says the deployed endpoint works.

GET reads a resource and changes nothing. POST creates a new one. PUT replaces a resource wholesale. PATCH updates part of it. DELETE removes it.

The distinction interviewers listen for is safety and idempotency: GET is safe (no side effects); GET, PUT and DELETE are idempotent (same request twice = same end state); POST is neither — call it twice and you may create two resources.

2xx succeeded — 200 OK, 201 Created, 204 No Content. 3xx redirect. 4xx the client's fault — 400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 409 conflict, 422 unprocessable. 5xx the server's fault — 500 internal error, 503 unavailable.

The line that matters in an interview: 401 means "I don't know who you are", 403 means "I know who you are and you can't". Mixing those up is a real, common API bug you should be testing for.

PUT replaces the whole resource — whatever you don't send, the server may blank out. PATCH updates only the fields you send and leaves the rest alone.

The test that catches the real bug: PATCH a single field, then GET the resource and assert every OTHER field is unchanged. Teams routinely implement PATCH as a disguised PUT, silently nulling fields the client didn't include — and it only shows up when a user loses data.

Resources addressed by URL (/orders/42), acted on with HTTP methods, communicating via representations (usually JSON), statelessly — every request carries what the server needs, nothing is remembered between calls.

In practice most "REST" APIs are pragmatic, not textbook. What matters for testing is the statelessness: if an endpoint depends on hidden server-side session state, that's your bug hunting ground — replay a request in isolation and see if it still works.

First get a valid credential the way a real client does, then prove the endpoint enforces it. For a Bearer/JWT flow: obtain a token, send it in the Authorization header, and assert the happy path works.

Then test the enforcement, which is where the bugs are: no token → 401, malformed token → 401, expired token → 401, valid token but wrong permissions → 403, and another user's token → they can't reach your data. The negative cases are the test, not the happy path.

The status code is table stakes. Then: the body's structure (the fields you depend on exist, with the right types), the values (the ones the request should have changed), key headers (content-type, cache, rate-limit), and response time if it's on a budget.

A 200 with a broken body is the failure a lazy test misses. Asserting status == 200 and stopping is how a green suite ships a null where a customer name should be.

You assert the response matches a defined shape — field names, types, what's required, what's nullable — with a JSON Schema validator or a typed model (pydantic, a POJO, a Zod schema). One assertion covers the whole structure.

You bother because value checks and schema checks catch different bugs. Your value test asserts price == 41.98; it says nothing about the day price starts arriving as a string, or a required field silently disappears. The schema is your early warning for contract drift.

Take the happy path apart: missing required fields, wrong types, empty and null values, boundary values (0, negative, max length, one over), malformed JSON, extra unexpected fields, and duplicate submissions.

Then the ones people forget: SQL/script-looking input in string fields, a huge payload, wrong content-type, and unauthorised access to someone else's resource. The happy path is one test; the interesting coverage is everything the endpoint should reject cleanly — with the right 4xx, not a 500.

Each test owns its data. Create what you need in setup (via the API or a seed), use it, and clean it up in teardown — so tests don't depend on a shared record another test might change or delete.

The anti-pattern is tests that assume 'user 42 exists' or run in a fixed order. Those pass locally and fail in CI the moment they run in parallel or someone edits the seed. Self-contained data is what makes an API suite safe to run parallel and repeatable.

Postman for exploring, one-off checks, and sharing a collection with people who don't code — it's fast to poke at an API and see what it does. Code (REST Assured, Python requests + pytest) for anything that has to run in CI, share setup, loop over data, or live beside the rest of the automation.

The honest interview answer: start in Postman to understand the API, then rebuild the checks in code once they're worth keeping. Postman collections in CI via Newman exist, but a real framework outgrows them.

Layer it. A thin client/service layer wraps the HTTP calls (one place per endpoint, so a URL change is one edit). Tests call those methods and assert — they never build raw requests inline. Config (base URLs, credentials) comes from the environment, not hardcoded. Data setup/teardown is in fixtures. Schemas live in one place and are reused.

The test reads like intent — createOrder(); assertStatus(201); assertSchema(order) — and the HTTP mechanics hide behind it. That separation is what lets the suite survive an API that keeps changing.

Pagination: assert the page size is honoured, the cursor/offset advances without repeating or skipping items, the last page ends cleanly, and totals are consistent while data is stable. The classic bug is items shifting between pages when the underlying list changes mid-scan.

Rate limiting: send requests past the limit and assert you get 429 (not 500), that the Retry-After/limit headers are correct, and that the counter resets when it should. And check the limit is per the right key — per user, not global, or one noisy client starves everyone.

Explore first, document as you go. Watch the app's network traffic to see real requests, or read the code if you can. For each endpoint, map the method, required and optional params, auth, and the response shape by making calls and observing — building a mini-spec from what you find.

Then turn that spec into tests: the happy path, the negative cases, the schema you just reverse-engineered. The write-up you produce is itself valuable — you've documented an undocumented API, which the team probably needed anyway.

Send the POST with a valid body, assert 201 and that the response includes the new id and echoes the data. Then GET that id and assert the resource actually persisted with the right values — creation isn't proven until you can read it back.

Then the edges: POST the same thing again (duplicate — does it 409 or create a second?), POST with a missing required field (400/422), and clean up the created resource in teardown. The round-trip plus the negatives is the full test; asserting only the 201 is half of it.