42 API testing interview questions with model answers

What they are assessing

Whether you understand the economics of testing lower in the stack.

Model answer

API testing verifies the business logic, data handling and contracts of a service directly, without a browser. Testing there is faster, more stable and more precise: a failure points at a specific endpoint rather than somewhere in a rendered page, tests run in seconds instead of minutes, and there is no locator or rendering fragility. It also lets you test before any UI exists, which shifts feedback earlier. The UI layer still matters, but it should verify rendering and journeys, not business rules that are cheaper and more reliably checked underneath.

Likely follow-up

So what would you still test through the UI?

What they are assessing

Basic vocabulary, and whether you have met anything other than REST.

Model answer

SOAP is a protocol with a strict XML envelope, a WSDL contract, and built-in standards for security and transactions, which is why it persists in banking and enterprise integrations. REST is an architectural style over HTTP, typically JSON, using standard verbs and status codes, lighter and more flexible but with no single enforced contract format. Practically, SOAP testing leans on the WSDL and XML schema validation, while REST testing leans on status codes, JSON schema and, increasingly, an OpenAPI specification serving the same contract role.

What they are assessing

Breadth. Weak candidates check only the status code and happy-path body.

Model answer

Status code, response body correctness against the expected schema and values, response headers including content type and caching, and response time against an agreed threshold. Beyond a single call: error handling for invalid input and missing fields, authentication and authorisation behaviour, boundary and negative cases, data persistence so the side effect actually happened, and idempotency where the verb implies it. I also check that error responses are structured consistently and do not leak internals such as stack traces.

Trap to avoid

Answering "check the status code is 200". Interviewers use this question to find out whether you validate the body, headers and side effects too.

What they are assessing

Precision on overlapping terms.

Model answer

API testing verifies a service through its interface, usually in isolation with dependencies stubbed. Integration testing verifies that components work together, so real dependencies are in play and the failure surface is wider. Contract testing verifies that a consumer and a provider agree on the shape of their interaction, typically with a tool like Pact, so each side can be tested independently and a breaking change is caught in the provider pipeline rather than in a shared environment. They answer different questions: does my service behave correctly, do these services work together, and will your change break me.

Likely follow-up

Where does contract testing fit in a microservices pipeline?

What they are assessing

Whether you exploit the contract rather than hand-writing everything.

Model answer

It is a machine-readable description of the API: endpoints, parameters, request and response schemas, status codes and auth. In testing it gives you three things. It is the oracle for what correct looks like, so schema validation can be automated directly against it. It generates a baseline of tests and client code, which saves writing boilerplate. And it is testable itself: comparing the live responses against the spec catches drift where the implementation and documentation have diverged, which is one of the most common real defects in an API estate.

What they are assessing

Understanding of a property that matters enormously for retries and payments.

Model answer

An idempotent operation produces the same resulting state whether it is performed once or many times. GET, PUT and DELETE are expected to be idempotent, HEAD and OPTIONS too, while POST is not. It matters because networks retry: if a client times out and resends, a non-idempotent POST can create two orders or two charges. That is why payment and order APIs usually accept an idempotency key so the server can recognise a repeat and return the original result rather than acting twice. Testing that behaviour explicitly is one of the highest-value API tests you can write.

Likely follow-up

How would you test an idempotency key implementation?

What they are assessing

Verb semantics, frequently confused.

Model answer

POST creates a resource or triggers a process, is not idempotent, and typically returns 201 with a Location header. PUT replaces a resource entirely at a known URI and is idempotent, so sending it twice leaves the same state. PATCH applies a partial update, changing only the supplied fields. The practical test implication is that PUT with a partial payload should generally null or reject the missing fields rather than silently preserving them, and confirming which behaviour the API actually implements is a genuine test worth writing, because implementations vary.

What they are assessing

Fluency with the vocabulary you will use all day.

Model answer

2xx is success: 200 OK, 201 Created for a new resource, 204 No Content for a successful call with nothing to return. 3xx is redirection, such as 301 permanent and 304 Not Modified for caching. 4xx is client error: 400 Bad Request for malformed input, 401 Unauthenticated, 403 Authenticated but not permitted, 404 Not Found, 409 Conflict, 422 Unprocessable Entity for semantically invalid input, 429 Too Many Requests. 5xx is server error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.

Likely follow-up

What is the difference between 401 and 403, precisely?

What they are assessing

A precise distinction that reveals whether you have tested auth properly.

Model answer

401 Unauthorized actually means unauthenticated: the request lacks valid credentials, and the response should include a WWW-Authenticate header telling the client how to authenticate. 403 Forbidden means the server knows who you are and you are not allowed, so retrying with the same credentials will not help. Teams get it wrong by returning 403 for an expired token, which misleads clients into not refreshing, or by returning 401 for a permission failure. Some APIs deliberately return 404 instead of 403 to avoid revealing that a resource exists, which is a legitimate security choice worth confirming rather than reporting as a bug.

Trap to avoid

Saying 401 is "not authorised" without distinguishing authentication from authorisation. That is the entire point of the question.

What they are assessing

Nuance, and whether you think about API design quality, not just pass or fail.

Model answer

400 Bad Request is for a request the server cannot parse or that is structurally wrong, such as malformed JSON or a missing required parameter. 422 Unprocessable Entity is for a request that is syntactically valid but semantically wrong, such as an end date before a start date, or an email that parses but fails a business rule. Not every API makes the distinction, and consistency matters more than the specific choice, so in testing I check that the API is internally consistent and that the error body identifies which field failed and why.

What they are assessing

Whether you look past the body.

Model answer

Content-Type on both request and response, since a mismatch causes real client failures. Authorization for auth flows. Cache-Control and ETag for caching behaviour, including whether a conditional request correctly returns 304. Location on 201 responses. Rate-limit headers such as X-RateLimit-Remaining and Retry-After on 429. CORS headers where a browser client is involved. And security headers: Strict-Transport-Security, X-Content-Type-Options, and confirming that sensitive data is not being placed in headers or query strings where it will land in logs.

What they are assessing

Whether you can scale response validation.

Model answer

Schema validation checks the whole response shape in one assertion: which fields exist, their types, required versus optional, formats such as date-time or email, enumerated values and nested structure. It matters because field-by-field assertions only catch what you thought to check, so a field silently changing type from number to string, or a new required field appearing, passes unnoticed. Schema validation catches structural drift, which is the failure mode that breaks consumers. I combine both: schema for shape, targeted assertions for the specific business values a test is about.

Likely follow-up

Where would the schema itself come from?

What they are assessing

Systematic thinking about a very common response pattern.

Model answer

Verify the first page returns the expected page size and the metadata is correct: total count, page number, and next or previous links. Then the boundaries: page beyond the last page returns an empty list rather than an error, page size at its maximum and beyond the maximum, page zero or negative, and a non-numeric page value. Check that ordering is deterministic, because unstable sort produces duplicate or missing records across pages, which is a real and easily missed defect. Finally confirm that filters and sorting combine correctly with pagination and that the total reflects the filter.

Likely follow-up

How would you detect records being skipped between pages?

What they are assessing

Whether you treat errors as a first-class contract.

Model answer

Errors are part of the contract, so I check the status code is semantically right, the error body follows a consistent structure across the API, it identifies the specific field or reason rather than saying something generic, and it carries a stable machine-readable code that clients can branch on rather than parsing English text. I also verify the negative security property: no stack traces, SQL fragments, internal hostnames or library versions in the response. Inconsistent error shapes across endpoints are worth raising as a defect even when each one individually works, because they force every consumer to write special cases.

What they are assessing

Whether you verify side effects rather than trusting the response.

Model answer

A 201 with a body only tells you what the service said, not what it stored. I verify the side effect through a subsequent GET on the created resource, checking the fields round-trip correctly, including ones the create response omitted. Where it matters, I also verify at the database level or through the downstream consumer, particularly for asynchronous flows where the write happens after the response. Fields that commonly break here are dates and timezones, decimal precision on money, unicode and emoji in text, and fields silently truncated to a column length.

What they are assessing

Whether you can test eventual consistency without flaky sleeps.

Model answer

The immediate response usually returns 202 Accepted with a job or status URL. I assert on that first, then poll the status endpoint with a bounded timeout and a sensible interval until it reaches a terminal state, rather than sleeping a fixed duration. Where a webhook signals completion, I stand up a listener and assert on the callback payload, including that it is signed and that duplicate deliveries are handled. The cases people miss are the failure terminal state, a job that never completes within the timeout, and out-of-order or repeated webhook delivery, all of which happen in production.

Likely follow-up

How would you test that a webhook is delivered exactly once?

What they are assessing

Practical familiarity across schemes.

Model answer

Basic auth sends base64-encoded credentials on every request, which is only acceptable over TLS and is rare in modern APIs. API keys identify a client, usually in a header, and are simple but carry no user context and no expiry unless rotated. Bearer tokens, commonly JWTs, carry claims and an expiry and are checked by signature. OAuth 2.0 is an authorisation framework with several flows, most commonly authorisation code with PKCE for user-facing clients and client credentials for service-to-service. Session cookies still appear in browser-facing APIs and bring CSRF considerations that token schemes do not.

Likely follow-up

What would you test differently for a JWT versus an opaque token?

What they are assessing

Depth on the most common modern scheme.

Model answer

Valid token grants access and the claims are honoured. Then the negatives, which is where the defects are: expired token rejected, token with a tampered payload rejected because the signature no longer verifies, token signed with the wrong key rejected, and critically a token with the algorithm set to none rejected, since accepting that is a classic authentication bypass. Also check that the token is validated on every protected endpoint rather than only at a gateway, that expiry is actually enforced rather than merely present, and that logout or revocation genuinely invalidates where the design claims to support it.

Trap to avoid

Only testing the happy path with a valid token. Every meaningful JWT defect lives in the rejection cases.

What they are assessing

Whether you test the lifecycle rather than a single moment.

Model answer

Verify the access token stops working exactly when it should, that the refresh token exchanges for a new valid access token, and that a used or revoked refresh token is rejected if the design uses rotation. Test the race where two requests refresh simultaneously, which commonly produces one invalidated token and a spurious logout. Confirm the refresh token has a longer, enforced lifetime of its own, and that logout invalidates both. For test suites, I usually shorten the token lifetime in the test environment rather than waiting out a real expiry, which keeps the test fast and deterministic.

What they are assessing

Whether security is part of your default coverage or someone else problem.

Model answer

Authentication enforced on every protected endpoint, not just the obvious ones. Authorisation checked per object, so changing an ID in the path does not return someone else data. Input validation against injection payloads in every parameter, including headers and query strings. Rate limiting present on authentication and expensive endpoints. Sensitive data absent from responses, logs and URLs, including that passwords and tokens are never echoed. TLS enforced with HTTP rejected or redirected. And error responses that do not leak internals. These are routine checks, not a substitute for a penetration test.

Likely follow-up

Which of those do you think teams most often miss?

What they are assessing

Knowledge of the most common and damaging real API vulnerability.

Model answer

Broken object level authorisation, top of the OWASP API Security list, is when an endpoint checks that you are logged in but not that the specific object belongs to you. Testing it is simple and rarely done systematically: authenticate as user A, capture a resource identifier, then request it as user B and confirm a 403 or 404 rather than the data. Do that for every endpoint taking an identifier, including nested routes, bulk endpoints, and export or report functions which are frequently overlooked. Also try sequential and guessable identifiers, since predictable IDs turn the flaw into mass data exposure.

Trap to avoid

Treating this as a penetration testing concern outside normal QA. It is a functional authorisation bug and it is cheap to catch in routine testing.

What they are assessing

Practical technique on a feature that protects availability.

Model answer

Send requests above the documented threshold and confirm the API returns 429 rather than degrading or accepting everything, then check the response carries Retry-After and any rate-limit headers, and that requests succeed again after the window resets. Verify the limit is scoped correctly, per user or per key rather than globally, so one noisy client cannot lock everyone out. Confirm the limit applies to authentication endpoints, which is where it matters most for brute-force protection. And check the limit is enforced server-side rather than only in the client SDK.

What they are assessing

Whether you use Postman as a tool or as a toy.

Model answer

Collections group requests into flows and can be organised per service or per journey. Environments hold variables so the same collection runs against dev, staging and production without edits. Pre-request scripts prepare state such as fetching a token, and test scripts assert on status, body and headers in JavaScript. Variables chain requests, so a created ID from one call feeds the next. Collection Runner executes a whole flow, optionally data-driven from CSV or JSON. And Newman runs the collection from the command line, which is how it enters CI.

Likely follow-up

What are the limits of keeping your regression suite in Postman?

What they are assessing

Whether you have taken API tests beyond a local GUI.

Model answer

Newman is the command-line runner for Postman collections, so the same collection and environment files execute in a pipeline and emit machine-readable reports such as JUnit XML for the CI dashboard. The practical caveats matter: collections and environments must be version controlled alongside the code rather than living in a shared cloud workspace nobody reviews, secrets come from CI variables rather than committed environment files, and the suite should be tiered so a fast smoke collection gates commits while the full run is scheduled. Beyond a certain size, teams usually migrate to a code-based framework for better reuse and review.

What they are assessing

Tool judgement rather than loyalty.

Model answer

Postman is excellent for exploration, debugging and sharing a request with a developer, and it is quick for small suites. I move to a code-based framework such as REST Assured, requests with pytest, or supertest when the suite needs real software engineering: shared helper libraries, proper code review through pull requests, complex setup and data builders, reuse of the same models the application uses, and tight integration with the rest of the test codebase. The deciding factor is usually maintainability at scale, since large Postman collections become hard to review and easy to duplicate.

What they are assessing

Whether you can isolate a service under test.

Model answer

Tools such as WireMock, MockServer, Prism or a language-native mock server stand in for a dependency, returning controlled responses. I stub when the dependency is third-party and not controllable, when I need to force conditions the real service will not produce on demand such as timeouts, 500s and malformed payloads, when the real call is slow or costs money, or when the dependency is not built yet. What I do not do is stub everything and then claim integration confidence, because a stub encodes my assumption of the other service behaviour, which is exactly what contract testing exists to verify.

Likely follow-up

How do you stop your stubs drifting from the real service?

What they are assessing

Framework thinking at the API layer.

Model answer

Separate layers: a thin client or service wrapper per API that knows the endpoints, headers and auth, request and response models rather than raw strings, reusable data builders for payloads, and tests that read as business intent with the assertions in them. Configuration and secrets external per environment. Auth handled once and reused rather than logging in on every test. Tests independent, creating and cleaning their own data so they can run in any order and in parallel. Then tiering: a fast smoke set for every commit, full regression on a schedule or pre-release.

What they are assessing

The most common source of flaky API suites.

Model answer

Prefer creating what a test needs through the API itself at setup, so the test is self-contained, then cleaning up afterwards. Generate unique values for anything unique-constrained, such as emails, so parallel runs and repeated runs do not collide. Avoid depending on pre-existing records in a shared environment, because someone will change them. Where a fixed dataset is unavoidable, treat it as a versioned seed the team owns and reset it deterministically. And keep production data out of test environments, using masked or synthetic data instead.

Likely follow-up

What do you do when the API has no delete endpoint to clean up with?

What they are assessing

Whether you place tests by feedback speed.

Model answer

API tests are the natural gate because they are fast and stable enough to run on every commit. I run a smoke set on pull requests, the full functional suite on merge to main, and contract tests in both consumer and provider pipelines so a breaking change fails the provider build rather than a shared environment. Tests run against an ephemeral or per-branch environment where possible, so runs do not contend for shared data. Results publish as JUnit XML with the failing request and response captured, because a failure with no payload wastes the next hour.

What they are assessing

Whether your knowledge extends past REST.

Model answer

GraphQL has a single endpoint and status codes are much less informative, since errors typically come back as 200 with an errors array, so asserting on the body is mandatory rather than optional. Testing focuses on the schema and resolvers: requesting exactly the fields needed, verifying nested resolution, and checking that unauthorised fields are rejected rather than silently null. Two GraphQL-specific risks matter: query depth and complexity limits, since an unbounded nested query is a denial-of-service vector, and the N plus 1 resolver problem, which is a performance defect visible only under realistic query shapes.

Trap to avoid

Assuming a 200 means success. In GraphQL a fully failed operation commonly still returns 200.

What they are assessing

Whether you can define and measure a target rather than "seeing if it is fast".

Model answer

Start from an agreed target expressed in percentiles rather than averages, since an average hides the tail that users actually feel, so something like p95 under 500 milliseconds at a stated concurrency. Model realistic load from production traffic patterns, including the mix of endpoints, not just the one under suspicion. Then run distinct test types: load at expected volume, stress beyond it to find the breaking point, soak to expose memory leaks and connection exhaustion, and spike for sudden bursts. Measure server-side too, because response time alone does not tell you whether the database, the pool or the CPU is the constraint.

Likely follow-up

Why do you prefer p95 over an average?

What they are assessing

Diagnostic reasoning rather than reporting the symptom.

Model answer

Narrow it layer by layer. Confirm it is the server and not the network or client by timing at the server. Check whether it is slow for all inputs or only some, which usually points at a missing index or an N plus 1 query pattern where a list endpoint queries per row. Look at the database: slow query logs, execution plans, and the number of queries per request. Check external calls made during the request, which are frequently the real cost. Check whether it degrades with concurrency rather than in isolation, which suggests pool exhaustion or lock contention. Then bring the developer evidence rather than a complaint.

What they are assessing

Systematic coverage on the most likely scenario question.

Model answer

Happy path: valid payload returns 201, the body matches what was sent, and a follow-up GET confirms persistence. Validation: each required field missing, wrong types, empty strings, whitespace-only values, over-length values, invalid email formats, and weak passwords if a policy exists. Uniqueness: creating the same email twice returns 409 rather than a second record or a 500. Security: injection payloads in every field, password never echoed in the response or logs, authorisation enforced if creation is restricted. Boundaries: field length limits, unicode and emoji, and leading or trailing whitespace handling. Idempotency: what a duplicate submission does.

Likely follow-up

The second create returns 500 instead of 409. What do you do?

What they are assessing

Reasoning about money, failure states and things you do not control.

Model answer

Use the provider sandbox for the happy path across card types and currencies, checking amounts and rounding to the minor unit. Then force what the sandbox will not produce on demand by stubbing: timeouts, 500s, malformed responses, and slow responses, verifying our retry, backoff and circuit-breaker behaviour. Test idempotency hard, because a retried charge that bills twice is the worst defect in this domain. Verify reconciliation: our order state matches the provider state, webhooks are handled including duplicate and out-of-order delivery, and signatures are validated. And check the awkward case where the charge succeeds but our order creation fails.

What they are assessing

Whether you reason about intent rather than pattern-matching a rule.

Model answer

It depends on what was requested. For a collection with no matches, 200 with an empty array is correct and a 404 would be wrong, because the collection exists. For a single resource that does not exist, 404 is correct and 200 with an empty body is a bug, since the client cannot distinguish missing from empty. If the endpoint genuinely has nothing to return, 204 No Content is the honest code. So my answer would be to check the specification, and if the specification does not say, that ambiguity is itself worth raising because every consumer will guess differently.

What they are assessing

Cross-boundary debugging, a very common real situation.

Model answer

Compare the two requests precisely rather than assuming. Capture the browser request from the network tab and diff it against the Postman one: headers, content type, auth token, cookies, body encoding and casing. The usual causes are CORS, since Postman does not enforce it and a browser does, including the preflight OPTIONS call being rejected; a missing or differently-formatted Authorization header; cookies not being sent because of SameSite or credentials settings; and content type mismatch where the client sends form data and the API expects JSON. Reproducing with curl using the exact browser headers usually isolates it in a couple of minutes.

Likely follow-up

How would you confirm it is specifically a CORS problem?

What they are assessing

Whether you shape a suite by cost of feedback.

Model answer

The large majority of functional coverage belongs at the API layer, because it is faster, more stable and pinpoints failures, with the UI reserved for rendering, navigation and a small number of critical end-to-end journeys. In practice I also use the API inside UI tests for setup, so a UI test starts at the screen under test rather than clicking through five screens to reach it. The signal that the balance is wrong is a UI suite that takes hours and fails for reasons unrelated to the UI, which usually means business logic is being verified in the most expensive possible place.

What they are assessing

Change management alongside technical knowledge.

Model answer

Start where the pain is, usually the pair of services that breaks each other most often, rather than mandating it estate-wide. Set up consumer-driven contracts with a broker so the consumer expectations are published and the provider pipeline verifies against them, which means a breaking change fails the provider build rather than being discovered in a shared environment days later. Show the team the first prevented incident, because that is what earns adoption. Then expand pair by pair. The failure mode is rolling it out everywhere at once: the contracts get written badly, the broker becomes noise, and the team concludes contract testing does not work.

Likely follow-up

What do you do when the provider team refuses to run consumer contracts?

What they are assessing

Whether you think about consumers and backward compatibility.

Model answer

The core question is what counts as a breaking change: removing or renaming a field, tightening validation, changing a type, or changing an error code all break consumers, while adding an optional field usually does not. So the suite needs regression against the previous version for as long as it is supported, and tests that specifically assert backward compatibility rather than only current behaviour. Schema comparison between versions in CI catches accidental breaks automatically. I also want the deprecation path tested: deprecation headers present, documented sunset date, and the old version still functioning until it is genuinely retired.

What they are assessing

Resourcefulness, and whether you leave things better than you found them.

Model answer

Find whatever contract exists: an OpenAPI file even if stale, the route definitions in the code, an existing Postman collection, or gateway logs showing real traffic and payload shapes. Talk to the developer for ten minutes, which usually beats an hour of guessing. Then explore systematically, recording each endpoint, its parameters and observed behaviour as I go, so the exploration produces documentation as a by-product. Document the assumptions I am testing against and get them confirmed, since anything ambiguous becomes a question rather than a silent guess, and those questions usually surface the real requirements.

What they are assessing

Pipeline design judgement.

Model answer

Anything fast, deterministic and covering a critical path belongs on every commit, because that is where fast feedback pays. Tests that are slow, that depend on third-party sandboxes, that need large data setup, or that are inherently timing-sensitive go to a scheduled or pre-release run so they do not make the commit gate unreliable. The rule I apply is that if a test fails for reasons unrelated to the change being made, it must not block the commit, because a gate people learn to ignore or bypass is worse than no gate at all.

What they are assessing

Balanced awareness rather than presenting API testing as free.

Model answer

There is no visual feedback, so you have to know what correct looks like from a contract rather than seeing it. Coverage can feel complete while a real user journey is still broken, because the pieces work and the composition does not. Setting up realistic data and auth is often harder than clicking through a UI. Asynchronous and event-driven flows are genuinely difficult to assert on. And documentation is frequently missing or stale, so the oracle itself is unreliable. None of this outweighs the speed and stability advantages, but pretending API testing is trivial is how gaps appear.