API Testing Interview Questions & Answers (2026)

An operation is idempotent when performing it N times leaves the server in the same state as performing it once. GET, HEAD, PUT and DELETE are defined as idempotent; POST and PATCH are not (PATCH can be, but is not required to be).

It matters because clients, proxies and load balancers retry. If a payment endpoint is POST and the client retries after a timeout, the customer can be charged twice. The testable requirement is usually an idempotency key: send the same key twice and assert the second call returns the original result rather than creating a second resource.

• 400 — the request itself is malformed: unparseable JSON, wrong type, missing required field.
• 401 — no credentials, or credentials that are invalid/expired. "I don't know who you are."
• 403 — credentials are valid but this identity is not allowed. "I know who you are, and no."
• 404 — the resource does not exist, or deliberately hides existence from an unauthorised caller.
• 409 — a state conflict: duplicate unique field, editing a stale version, deleting something still referenced.
• 422 — syntactically valid but semantically invalid: a well-formed date that is in the past when it must be future.

The 401/403 boundary is the one interviewers probe. A useful test is that 401 responses should include a WWW-Authenticate header, and that repeating the request with fresh credentials could succeed — which is never true of a 403.

PUT replaces the resource: fields you omit should be cleared or reset to defaults. PATCH applies a partial change: omitted fields must be left untouched.

The decisive test for PUT is to send a payload missing an optional field and assert the stored value was actually removed — many implementations quietly behave like PATCH, which is a real defect because clients rely on replace semantics. For PATCH, the decisive test is that a second unrelated field is unchanged, and that sending an explicit null is distinguishable from omitting the key.

Path identifies a resource: /orders/1001. It should be required and part of the resource's identity.

Query modifies a collection request: filtering, sorting, pagination, field selection — /orders?status=shipped&sort=-created&page=2. Optional by nature.

Headers carry metadata about the request rather than the resource: authentication, content negotiation, correlation IDs, caching validators.

Testable smells: an identifier in the query string when it is really part of the path; authentication tokens in query parameters, where they end up in server logs and browser history; and pagination in headers rather than the body when clients cannot read them cross-origin.

Beyond "page 1 returns 20 items":

• Total count consistency — does the sum of all pages equal the reported total?
• No duplicates or gaps across page boundaries, especially with default ordering that is not unique. Sorting by a non-unique created_at is the classic cause of an item appearing on both page 1 and page 2.
• Last page and beyond — an empty array with 200, not a 404 or an error.
• Boundary values for limit: 0, 1, the documented maximum, above the maximum (should clamp or 400, never dump the whole table).
• Cursor pagination: an invalid or expired cursor, and behaviour when rows are inserted mid-traversal.

Correctness first: each filter alone, filters combined (AND semantics), a filter matching nothing, and case sensitivity. For sorting, ascending and descending on each documented field, a stable secondary sort for ties, and sorting combined with pagination — the pairing is where most defects live.

Then robustness: an unknown field name, an unsupported operator, and a value containing SQL or NoSQL metacharacters. A safe implementation rejects unknown sort fields with 400; an unsafe one interpolates them into a query. That single test catches a serious class of vulnerability without needing a security tool.

REST is a set of architectural constraints: a uniform interface, statelessness, client–server separation, cacheability, layered system, and resource identification through URIs with representations transferred to the client.

Most APIs called REST satisfy some of them. The consequential ones for testing are statelessness — every request carries what it needs, so you can verify no hidden server session exists by making calls out of order or from different connections — and cacheability, which means Cache-Control and ETag behaviour is part of the contract, not an optimisation detail.

The client states what it wants with Accept and describes what it sends with Content-Type; the server responds with the chosen representation and a matching Content-Type.

Tests worth having: an unsupported Accept should return 406, not silently return JSON; a wrong Content-Type on a POST should return 415, not attempt to parse; a missing Content-Type with a body; and charset handling for non-ASCII payloads. Where an API supports both JSON and XML, the same resource must round-trip equivalently in both.

A complete assertion set covers five layers:

1. Status — the exact code, not just "2xx".
2. Headers — content type, cache directives, correlation ID, security headers, and Location on a 201.
3. Schema — types, required fields, enum values, nullability; not just field presence.
4. Business data — the values actually reflect the request and the system state.
5. Non-functional — response time within the agreed budget, and payload size within reason.

A test asserting only status === 200 will pass happily while the API returns an empty object.

A machine-readable error code that clients can branch on, a human-readable message, the offending field(s) for validation errors, and a correlation ID that maps to server logs. A standard shape such as RFC 9457 problem details is a reasonable target.

Test that error shape is consistent across endpoints — mixed formats break every client's error handling — and that messages never leak stack traces, SQL fragments, internal hostnames or whether a username exists. That last point matters: "user not found" versus "wrong password" is a user-enumeration defect.

• Basic Auth — base64 of user:password on every request. Not encryption; only acceptable over TLS and mainly for internal or legacy systems.
• API key — a shared secret identifying a client application, not a user. Good for rate limiting and quotas, weak for user-level authorization.
• OAuth 2.0 — a delegation framework: how a user grants a third-party app limited access without sharing credentials. It defines flows, not token formats.
• JWT — a token format: signed, self-describing claims. Often used as the access token inside OAuth, but the two are not alternatives to each other.

The precision that scores points: OAuth is authorization delegation, JWT is a serialisation format, and saying "we use OAuth instead of JWT" is a category error.

Three base64url segments: header (algorithm, key id), payload (claims such as sub, exp, iat, aud, iss, roles), and signature. The payload is encoded, not encrypted — anyone holding the token can read it, so it must not contain secrets.

Tests worth running: an expired token is rejected (401, not 403); a token signed with the wrong key is rejected; a token with the algorithm switched to none is rejected; a valid token from a different audience or issuer is rejected; and claims are actually enforced rather than merely present — flipping a role claim without re-signing must fail.

Authentication establishes identity; authorization decides what that identity may do.

Authentication test: call a protected endpoint with no token, an expired token and a malformed token — all should return 401.

Authorization test: authenticate as a low-privilege user and call an admin endpoint — 403. Then the more valuable variant: authenticate as user A and request user B's resource by ID. If it returns B's data, that is a broken object-level authorization defect, one of the most common and most serious API bugs, and it is invisible to any test that only uses one account.

Cases that matter: an access token used just after expiry returns 401; the refresh token exchanges for a new access token; a refresh token that has already been used is rejected if the API implements rotation; a revoked or logged-out refresh token fails; and refresh tokens do not outlive an account deactivation.

Practically, do not wait for real expiry. Either request a short-lived token from a test-only configuration, or manipulate time server-side in the test environment. Sleeping for an hour in CI is not a test strategy.

Cookie sessions are sent automatically by the browser, which introduces CSRF exposure and means the API must validate an anti-CSRF token or enforce SameSite. Bearer tokens are attached deliberately by the client and are not auto-sent, so CSRF is less relevant but token storage becomes the risk.

For testing: with cookies you need a client that maintains a cookie jar, and you should verify HttpOnly, Secure and SameSite attributes are set. You should also verify the session cookie is rotated on login (session-fixation defence) and invalidated server-side on logout — not merely cleared client-side.

Client credentials is machine-to-machine: the client posts its ID and secret to the token endpoint and receives an access token, with no user involved.

It is the right flow for test automation against service APIs because there is no browser redirect to drive. For user-facing APIs, tests normally use either a dedicated test-only token endpoint or the resource owner password flow in a non-production environment. What you should avoid is scripting a browser through a login screen just to obtain a token for an API test — it is slow and couples your API suite to UI changes.

Focus on functional security defects that fall naturally out of test design, always against environments you are authorised to test:

• Object-level authorization: can user A read/modify user B's records by changing an ID?
• Function-level authorization: can a normal user reach admin endpoints directly, bypassing a UI that merely hides the button?
• Mass assignment: can you set "role": "admin" or "isVerified": true in a profile-update payload?
• Information disclosure in errors and in over-broad responses returning fields the client never needs.
• Transport and headers: HTTPS enforced, no credentials in URLs, sensible CORS rather than a wildcard with credentials.
• Rate limiting present on authentication endpoints.

Deeper work — fuzzing, injection exploitation, dependency exploits — belongs with a security team and explicit authorisation.

Never in the repository — not in collection exports, not in config files, not in fixture JSON. Inject them from the CI secret store as environment variables, and read them at runtime.

Additional practices worth stating: use dedicated test accounts with the minimum scope required; prefer short-lived tokens minted per run over long-lived static keys; mask secrets in logs, because a failing request logger will otherwise print the Authorization header into a public build log; and rotate anything that has been exposed rather than assuming a private repository is safe.

Work outward from the contract in a fixed order so nothing is skipped:

1. Happy path — the documented request produces the documented response and the documented side effect.
2. Schema and contract — every field type, requiredness and enum, plus the error shape.
3. Input space — equivalence classes and boundaries for each parameter.
4. Negative — missing, wrong-typed, oversized and malformed inputs.
5. Authorization — each role, plus cross-tenant access.
6. State — idempotency, concurrency, ordering, and what happens on a repeated call.
7. Non-functional — response time budget, rate limiting, timeout behaviour.

Then prune by risk: not every endpoint deserves all seven layers, but the decision should be explicit rather than accidental.

• Missing required field; empty string versus explicit null versus omitted key — these are three distinct cases and frequently behave differently.
• Wrong type: numeric where a string is expected, array where an object is expected.
• Malformed JSON, and an empty body.
• Field over its maximum length, and exactly at the limit.
• Duplicate email — expect 409, and confirm no partial record was created.
• Extra unexpected fields, including privileged ones such as role or id.
• Unicode, emoji, RTL text and leading/trailing whitespace in the name.
• Content-Type mismatch.

For each, assert the status, the error shape and — critically — that the system state is unchanged.

The boundaries are the same idea applied to different surfaces: numeric fields (min−1, min, min+1, max−1, max, max+1), string lengths, array sizes in a bulk endpoint, page size limits, date ranges spanning month and year ends, and integer overflow at 32-bit and 64-bit limits.

Two API-specific boundaries people forget: the maximum accepted request body size (assert a clean 413 rather than a connection reset), and numeric precision — a price sent as 0.1 + 0.2 in a float field, or an ID beyond JavaScript's safe integer range being silently rounded by a JS client.

Chaining means using a value from one response in the next request — create an order, capture its ID, fetch it, then cancel it.

It is necessary, but it couples tests: a failure in step one produces cascading failures that obscure the real defect, and the chain cannot run in parallel. Mitigations: keep chains short and scoped to one scenario; create prerequisites through the fastest available route (a direct setup endpoint or database seed) rather than a long UI-like chain; assert each step so the failure points at the right call; and make each test create its own data instead of depending on an earlier test's leftovers.

Fire the competing requests simultaneously rather than sequentially, then assert on the aggregate outcome:

const results = await Promise.all(
  Array.from({ length: 10 }, () => post('/api/seats/12/book', { userId: rand() }))
);
const created = results.filter(r => r.status === 201);
expect(created).toHaveLength(1);          // exactly one winner
expect(results.filter(r => r.status === 409)).toHaveLength(9);

Then verify the database holds exactly one booking — the API can report correctly while still writing duplicates. Related cases: two PATCHes to the same record (does optimistic locking via ETag/If-Match work?), and a create-then-immediately-read against a read replica, which surfaces replication lag.

Driving one test body from a table of inputs and expected outputs — a CSV or JSON of payloads and expected status codes — keeps validation coverage readable and easy to extend.

It stops being useful when each row needs different setup or different assertions, at which point the test becomes a maze of conditionals that is harder to read than separate tests. It is also a poor fit for stateful sequences. A useful rule: if the data table needs a column that controls test logic rather than test data, split the test.

Prefer creating what you need per test through the API itself, with unique identifiers derived from a run ID, and deleting it afterwards. Where creation is not possible, partition: reserve a set of records or a tenant per pipeline so two runs cannot collide.

Avoid depending on data someone loaded manually months ago — it is the single largest source of "the suite fails on Mondays" reports. Where reference data genuinely must be static (currencies, tax codes), assert its presence in a pre-flight check so a missing prerequisite fails fast with a clear message rather than as twelve confusing assertion errors.

Find an observable surface and poll it with a bounded wait, rather than sleeping. Options in order of preference: a query API the product already exposes (audit endpoint, message status); a test double for the external system (a mail-catcher service, a test queue consumer); and direct infrastructure access (reading the queue or database) only where nothing else exists.

Always bound the wait and fail with a useful message: "no audit row for order 1001 after 20s" is diagnosable; a timeout on a generic assertion is not.

Rank endpoints by a combination of blast radius and change rate: payment, auth and anything writing to money or identity go first; read-only endpoints with stable contracts go last. Layer on evidence — which endpoints appear in incident history, which have the highest traffic, and which are consumed by third parties who cannot be redeployed with you.

Then match depth to rank: full seven-layer coverage for the top tier, contract plus happy path for the middle, and schema validation only for the long tail. Stating this trade-off explicitly is usually a better answer than claiming complete coverage.

A schema declares the shape once — types, required fields, enums, formats, nullability, additional-property rules — and every response is validated against it. Field-by-field assertions typically check only the handful of fields the author remembered, so a type change from number to string in an unchecked field ships silently.

The high-value setting is additionalProperties: false, which catches unannounced new fields — often the first visible sign that a backend has changed. Generate the schema from the API's OpenAPI definition rather than hand-writing it, so the schema and the documentation cannot drift apart.

Integration testing runs consumer and provider together and asserts the combined behaviour — realistic, but slow, and it needs both systems deployed.

Contract testing verifies each side against a shared contract independently. The consumer's expectations are recorded and replayed against the provider in the provider's own pipeline. The provider learns it broke a consumer before deploying, without anyone standing up a full environment.

It answers "does the interface still match?", not "does the business flow work?" — so it complements a small set of integration tests rather than replacing them.

Consumers publish the interactions they rely on; the provider verifies all published contracts in its build and cannot merge if one breaks.

Technically that needs a broker holding versioned contracts and a verification step in both pipelines. Organisationally it needs more: provider teams must accept a build that fails because of another team's expectations, contracts must be tied to deployed versions (so an old consumer's contract does not block forever), and someone must own retiring stale contracts. Without that agreement, contract tests get marked as allowed-to-fail and the value disappears.

Breaking: removing a field or endpoint, renaming a field, narrowing a type, making an optional request field required, adding a new required field, changing a status code for an existing condition, tightening validation, or changing the meaning of an existing value.

Non-breaking: adding an optional request field, adding a response field (if consumers tolerate unknown fields), adding a new endpoint or a new enum value in a field consumers treat as opaque.

Catch it by diffing the OpenAPI specification between commits with a compatibility checker in CI, and by running consumer contracts against the candidate build. Both are cheap and run before deployment.

Common approaches: URI versioning (/v1/orders) — most visible and easiest to route; header or media-type versioning — cleaner URIs but harder to inspect and cache; and date-based versioning pinned per client.

Whichever is used, the testing implication is the same: every supported version needs its own contract tests, because the deprecation window is when regressions appear. Practical additions worth arguing for — assert that a deprecated version returns a Deprecation/Sunset header, and keep at least a smoke suite running against the old version until it is genuinely switched off.

Three concrete uses. First, generate request/response schemas for validation so assertions stay in sync with the documented contract. Second, generate a baseline set of tests — every documented endpoint, method and required parameter — which gives cheap breadth. Third, verify the running API against the spec, catching endpoints that exist but are undocumented, or documented but missing.

The caveat to state: a spec proves shape, not behaviour. An endpoint can satisfy its schema perfectly while returning the wrong customer's data.

The concepts carry over; the mechanics differ. Validate against the XSD rather than a JSON schema, and against the WSDL for operation definitions. Namespaces matter — an assertion that ignores them will match the wrong element. SOAP faults replace HTTP status codes as the error channel, so a 200 response can still be a failure and must be parsed.

Other differences worth mentioning: XPath rather than JSONPath for extraction, and encoding/whitespace sensitivity that JSON does not have. If the API offers both XML and JSON representations, add a test that both express the same data.

Send requests past the documented threshold and assert: the limiting response is 429; Retry-After or X-RateLimit-* headers are present and accurate; the counter resets on the documented window; and the limit is scoped correctly — per API key, per user or per IP as specified, verified by confirming a second key is unaffected.

Also test that limiting does not corrupt state: a request rejected at the limit must not have partially executed. And run this in an environment where you are permitted to; deliberately exhausting a shared staging quota affects everyone else.

Connection timeout — the TCP/TLS handshake did not complete: usually DNS, firewall or the service being down.

Read (socket) timeout — the connection succeeded but the response did not arrive in time: usually a slow query or an upstream dependency.

Server-side timeout — the server itself gave up on a downstream call and returned 504 or 503.

The distinction changes the diagnosis completely: a connection timeout is an infrastructure question, a read timeout is a performance question, and a 504 is the service telling you which dependency failed. A test suite that reports all three as "request failed" wastes hours of triage.

Retries are safe for idempotent operations and for clearly transient failures — connection errors, 502/503/504, and 429 with a Retry-After. They are unsafe for non-idempotent POSTs without an idempotency key, and for 4xx errors that will never succeed on repeat.

Test with a fault-injecting mock: fail the first two attempts, succeed on the third, then assert the client retried the right number of times, honoured exponential backoff with jitter, and did not create duplicate resources. Also assert it eventually gives up — a client that retries forever turns a small outage into a self-inflicted denial of service.

A circuit breaker stops calling a failing dependency after a threshold of errors, returns a fast fallback while open, then allows a trial request after a cooldown (half-open) before closing again.

To verify: drive the dependency to fail past the threshold using a mock, then assert that subsequent calls return quickly with the fallback rather than waiting for a timeout — response time is the key evidence. Then restore the dependency and confirm the breaker closes after the cooldown, and that the fallback response is well-formed and clearly signalled rather than an empty 200 that clients mistake for real data.

Check the directives first: is Cache-Control what the contract says, and is anything user-specific marked private or no-store? A personalised response cached publicly is a data-leak defect.

Then validators: request with If-None-Match using the returned ETag and assert a 304 with no body; modify the resource and assert the ETag changes. Finally, assert freshness end-to-end — update a resource and confirm a subsequent read reflects it within the documented window, and that Vary is set correctly where responses differ by Accept or Authorization.

Functional API tests can reasonably assert a per-endpoint response-time budget under no load — it catches an accidental N+1 query or a missing index long before a load test is scheduled. They can also flag payload sizes that have grown unreasonably.

Load testing begins where concurrency, duration and think time matter: throughput at target concurrency, latency percentiles (P95/P99, not averages), error rate under sustained load, and behaviour past the breaking point. Those need a dedicated tool, a controlled environment and correlated server metrics — a single-threaded functional suite cannot produce meaningful numbers.

A correlation (or trace) ID travels with a request through every service and appears in every log line, letting you reconstruct one request's path across a distributed system.

In testing, generate one per test, send it as a header, and include it in the failure message. When an API test fails in CI, the engineer can search the platform logs for that exact ID rather than guessing which of thousands of requests was theirs. It also verifies the API's own propagation: assert the ID is echoed back and appears in downstream logs, because a service that drops it breaks production debugging.

Two directions. As the receiver, verify signature validation (a payload with a wrong or missing signature must be rejected), idempotency (the same event ID delivered twice must not double-process), out-of-order delivery, and that a slow handler still acknowledges within the provider's timeout so the provider does not retry unnecessarily.

As the sender, verify retry policy on non-2xx responses, backoff, and eventual dead-lettering. For test infrastructure, use a local receiver endpoint or a tunnelling service rather than depending on a real third party, and always assert the resulting state change, not just the HTTP 200 you returned.

A mock returns a canned response to a specific call, typically defined in the test. Service virtualization simulates a whole dependency with stateful, configurable behaviour — it remembers what you created, can vary latency and error rates, and is deployed as a standalone service that many teams and environments share.

You reach for virtualization when the real dependency is unavailable, charges per call, has limited test capacity, or cannot produce the scenarios you need (a bank's fraud rejection, a carrier's shipment exception). The risk to name: a virtual service is only as accurate as its last update, so it needs its own contract verification against the real system.

Mock what you do not own and cannot control deterministically: third-party payment, mail, SMS, identity providers, and anything charging per request. Also mock to reach failure states that are otherwise unreachable.

Do not mock the service under test, and do not mock your own internal dependencies in the integration layer — that is exactly the seam where contract drift causes production incidents. A reasonable split is unit and component tests heavily mocked, one integration layer with real internal services, and a small number of end-to-end tests touching real third-party sandboxes on a schedule.

Layer them by speed and blast radius: schema and contract checks on every commit (seconds); a functional API suite against an ephemeral or shared test environment on every merge (minutes); a full regression plus third-party sandbox tests nightly; and a small production smoke suite of read-only calls after deploy.

Operational details that make it work: fail fast with a pre-flight health check so a down environment reports clearly instead of producing 200 assertion errors; publish machine-readable results (JUnit XML) so failures surface in the build UI; and keep the merge-blocking suite under roughly ten minutes or people will start bypassing it.

1. Reproduce manually with the exact request, capturing full headers and body. Confirm it is not a test-side change.
2. Read the response: is there an error code and a correlation ID? Search the service logs for that ID.
3. Determine scope — one endpoint or many? One environment or all? One data set or any input? A 500 on a single record usually means data; a 500 on everything means deployment or configuration.
4. Check what changed: recent deploys, config or feature-flag changes, dependency versions, certificate expiry, and downstream service health.
5. Reduce the payload to the minimum that still fails. That usually identifies the offending field.

Report with evidence: the request, the correlation ID, the log excerpt and the minimal reproduction. A ticket saying "API returns 500 sometimes" gets bounced back.

In rough order of frequency: shared mutable test data between parallel runs; eventual consistency, where a read immediately after a write hits a replica that has not caught up; time and timezone dependence, including tests that break at month end; rate limiting triggered by the suite's own parallelism; hardcoded IDs that exist in one environment only; and ordering assumptions about collections that have no deterministic sort.

Notably absent: element waits and rendering — importing UI-flakiness explanations into an API discussion is a signal the candidate has not actually maintained an API suite.

Start where the pain is measurable. Pick the two or three slowest or flakiest UI journeys, and replace their setup with API calls — the suite gets faster immediately and nobody has to argue about strategy.

Next, add schema validation for the endpoints those journeys already call, which is nearly free once you have an HTTP client. Then move the validation-rule and error-path cases down from UI to API, deleting the UI versions so the suite shrinks rather than grows. Track two numbers throughout — total pipeline duration and failure triage time — because those are what convince a sceptical team, not coverage percentages.

Structurally: one endpoint, POST-based, and the client chooses the response shape. That breaks several REST habits — you cannot test by URL, HTTP status is usually 200 even for errors (failures appear in the errors array), and HTTP caching largely does not apply.

What to test instead: query and mutation correctness per field selection; the errors array shape and partial-data responses; authorization per field, not just per operation, because a single query can traverse into data the caller should not see; query depth and complexity limits, since an unbounded nested query is a denial-of-service vector; and schema evolution, where field deprecation replaces versioning.

Separate the layers: a thin HTTP client with auth and logging, typed request/response models generated from the spec, reusable data builders, and tests that read as business intent rather than plumbing. When the auth mechanism changes, one file changes.

Then the habits: schemas generated from the spec rather than hand-maintained; no hardcoded environment values; every test creating its own data; a quarterly pass deleting tests that duplicate coverage; and treating the suite as production code in review — same standards, same refactoring, same ownership. A suite nobody owns becomes a suite nobody trusts, and then it gets skipped.