Resource library

QA Interview

API Testing Interview Questions and Answers (2026)

Real API testing interview questions and answers on HTTP methods, status codes, authentication, schema validation, and contract testing for QA and SDET roles.

2,586 words | Article schema | FAQ schema | Breadcrumb schema

Overview

API testing is the round where interviewers separate people who click Send in Postman from people who actually understand the contract underneath. In 2026 almost every product is a set of services talking over HTTP, so the API interview has quietly become the most important technical conversation for QA and SDET candidates. This guide gives you the questions you will genuinely be asked, plus answers strong enough to move you to the next round.

The angle here is deliberately tool-agnostic. Whether your team uses REST Assured, Postman, Playwright, or plain requests, the interviewer is testing whether you understand HTTP, status codes, authentication, data contracts, and failure modes. We mix conceptual questions, scenario prompts where you have to reason under ambiguity, and hands-on checks on status codes and payloads.

Read each answer as a template, not a script. Say the core idea in your own words, then anchor it with one concrete example from a project you actually worked on. That combination of correct theory plus lived detail is what makes an interviewer stop taking notes and start nodding.

Core Concepts You Must Nail First

Interviewers almost always open with a warm-up to calibrate your level. The trap is answering these too briefly and sounding junior, or too vaguely and sounding like you memorized a blog. Give a crisp definition, then one line of nuance that shows real experience.

Q: What is the difference between API testing and UI testing? A strong answer: UI testing drives the application the way a human does, through rendered pages, and it is slower and more brittle because it depends on layout, timing, and the browser. API testing talks directly to the service layer over HTTP, so it is faster, more stable, and can validate business logic and error handling before any UI exists. I use API tests as the workhorse for regression and reserve UI tests for a thin layer of critical user journeys.

Q: What is a REST API? A: An architectural style using stateless HTTP requests, resources identified by URLs, and standard verbs (GET, POST, PUT, PATCH, DELETE) returning representations, usually JSON.
Q: REST vs SOAP? A: REST is lightweight, JSON-first, and stateless over HTTP; SOAP is a stricter XML protocol with a WSDL contract, built-in standards (WS-Security), and is still common in banking and legacy enterprise systems.
Q: What is an idempotent request? A: One that produces the same server state no matter how many times you send it. GET, PUT, and DELETE are idempotent; POST is not, which is why retrying a POST can create duplicate records.

HTTP Methods and Status Codes

Status codes are the single most common hands-on API question because they reveal instantly whether you read responses or just check for 200. Interviewers love to give you a scenario and ask which code the server should return, so practice reasoning from behavior to code, not just reciting the list.

Q: Walk me through the status code families and give a real example of each. Answer: 2xx means success (200 OK for a read, 201 Created after a successful POST, 204 No Content after a DELETE). 3xx is redirection (301 permanent, 304 Not Modified for caching). 4xx is a client mistake (400 malformed body, 401 not authenticated, 403 authenticated but not allowed, 404 resource missing, 409 conflict, 422 semantically invalid, 429 rate limited). 5xx is the server failing (500 unhandled error, 502 bad gateway, 503 unavailable, 504 timeout). The distinction I always call out is that a 4xx is the caller's fault and a 5xx is ours to fix.

Q: You POST a new order and get 200 instead of 201. Is that a bug? A: Not always broken, but it is a contract smell. If the API documents 201 with a Location header for creation, returning 200 breaks that contract and I would raise it.
Q: Difference between 401 and 403? A: 401 means the server does not know who you are (missing or expired token); 403 means it knows exactly who you are and you are still not allowed.
Q: When should an API return 422 instead of 400? A: 400 is for syntactically broken requests (bad JSON); 422 is for well-formed requests that fail business validation (email already registered).

What You Actually Validate Beyond 200 OK

This is the question that filters out shallow candidates. Anyone can assert a status code. The interviewer wants to hear a layered mental model of everything a response promises.

Q: When you test an endpoint, what do you assert beyond the status code? Answer: I validate in layers. First the status code and response time. Then the headers (content-type, cache-control, any pagination or rate-limit headers, security headers). Then the body against the schema, checking not just that fields exist but that their types, formats, and required-ness match the contract. Then the actual business values for the specific test data. Then side effects, meaning did the write actually persist and is it idempotent on retry. Finally the negative and boundary space: malformed input, missing auth, empty results, and oversized payloads. A response can return 200 and still be wrong in any of those layers.

Authentication and Authorization Questions

Auth is where security-conscious teams probe hardest, because a broken auth check is a headline waiting to happen. Be precise about the difference between proving who you are and proving what you are allowed to do.

Q: How do you test a role-gated endpoint? Answer: I build a matrix of identities crossed with actions. A valid token for an allowed role should return 200. A missing or expired token should return 401. A valid token for a role that lacks permission should return 403, not 404 and not 200. Then I test the dangerous edges: can user A read user B's resource by changing the ID in the URL (an IDOR / broken object level authorization bug), does a token still work after logout or password change, and does a low-privilege user get blocked from admin-only fields even inside an allowed endpoint.

Q: Explain OAuth2 bearer flow in one breath. A: Client authenticates, receives an access token, sends it as Authorization: Bearer <token> on each request; the server validates the token and its scopes per request.
Q: How do you test token expiry? A: Use an expired or soon-to-expire token and assert 401, then verify the refresh flow issues a new valid token and the old one is truly rejected.
Q: Where do you store secrets in an API test suite? A: In environment variables or a secrets manager, never hard-coded and never committed to the repo.

Scenario-Based Questions

Scenario prompts test judgment, not recall. There is no single right answer, so the interviewer is grading how you decompose ambiguity and where your instincts go first. Think out loud.

Q: A GET endpoint returns 200 in staging but users report stale data in production. How do you investigate? Answer: I separate the layers. First I confirm the API itself returns fresh data by calling it directly with production data and a cache-busting header, so I know whether the bug is in the service or in front of it. If the API is correct, I look at caching layers: CDN, reverse proxy, and client-side cache headers like ETag and max-age. I check whether a write in one region propagates to the read replica the GET hits, which is a classic eventual-consistency gap. Then I write a test that performs a write and polls the read endpoint until it reflects the change, capturing the propagation delay as evidence.

Q: The same POST occasionally creates duplicate records. What is happening and how do you test it? Answer: This is almost always a retry-on-timeout problem meeting a non-idempotent endpoint. The client times out, retries, and the server processes both because there is no idempotency key. I reproduce it by firing concurrent identical POSTs and asserting only one record is created, and I recommend the API accept an idempotency key so retries are safe.

Schema Validation and Data Contracts

Schema validation is where API testing earns its reliability. Field-by-field assertions rot the moment the payload grows; a schema check catches structural drift automatically. Expect the interviewer to push on why this matters.

Q: Why validate against a JSON schema instead of asserting individual fields? Answer: Because a schema is the contract in executable form. It catches new required fields, changed types (a number silently becoming a string), removed fields, and nested structure changes in one assertion, even for parts of the payload my test does not explicitly read. I still assert specific business values for my scenario, but the schema is my early-warning system for backward-incompatible changes that would otherwise reach consumers before anyone notices.

Q: What is contract testing? A: Verifying that a provider and consumer agree on the shape of requests and responses, so a provider change cannot silently break a consumer. Consumer-driven contract tools like Pact make this explicit.
Q: How is contract testing different from integration testing? A: Integration tests exercise real services wired together; contract tests verify the interface in isolation against a shared expectation, catching mismatches without spinning up the whole system.
Q: What breaks backward compatibility in an API? A: Removing or renaming a field, tightening validation, changing a type, making an optional field required, or changing status-code semantics.

Hands-On and Coding Questions

For automation roles, expect to write or read a small test live. You do not need to memorize a library API perfectly; you need to structure a test that a senior engineer would trust. Narrate the arrange, act, assert flow.

Q: Sketch an automated test for POST /users then GET /users/{id}. Answer: Arrange by building a valid user payload from a factory, not a hard-coded blob. Act by sending the POST with correct headers and auth, then assert 201 and capture the returned id and Location header. Then GET that id and assert 200, assert the body matches the schema, and assert the fields I sent came back unchanged. Teardown deletes the created user so the test is repeatable. The key details I mention: no dependency on test order, no shared mutable data, and the created id flows from the first call into the second rather than being hard-coded.

Q: How do you data-drive an API test? A: Externalize inputs into a table or file (CSV/JSON), iterate rows, and assert per row, covering positive, negative, and boundary cases.
Q: How do you keep API tests independent across environments? A: Create the data the test needs, use env-driven base URLs and secrets, avoid hard-coded IDs, and clean up after each run.
Q: How do you test pagination? A: Verify page size, the total count, that pages do not overlap or drop records, stable ordering, and the behavior of an out-of-range page number.

Performance, Rate Limiting, and Reliability

Even in a functional interview, teams want to know you think about the API under load, not just under happy-path conditions. You do not have to be a performance specialist, but you should speak the language.

Q: How would you test that an API enforces rate limiting? Answer: I send requests above the documented threshold within the window and assert the API responds with 429 Too Many Requests, then confirm it returns the right headers (Retry-After or the X-RateLimit family) so clients can back off. I also verify the limiter resets after the window and that legitimate traffic below the limit is never throttled. The subtle check is whether the limit is per user, per token, or per IP, because that changes both the test and the security story.

Q: What is the difference between latency and throughput? A: Latency is how long one request takes; throughput is how many requests per second the system handles. You can have low latency and still hit a throughput ceiling.
Q: How do you test API timeouts and retries? A: Simulate a slow or failing dependency, confirm the client times out cleanly rather than hanging, and verify retries are bounded and do not cause duplicate side effects.
Q: What does idempotency have to do with reliability? A: Safe retries depend on it; without idempotent writes, retrying a failed request can corrupt data.

Behavioral and Strategy Questions

The loop usually closes with judgment questions. These are not filler; a staff engineer is deciding whether they would trust you to own quality for a service. Answer with ownership and trade-offs, not textbook ideals.

Q: Your API test suite is flaky and the team has started ignoring failures. What do you do? Answer: A test suite nobody trusts is worse than no suite, so I treat this as a priority-one problem. I quarantine the flaky tests immediately so the signal is clean again, then root-cause each one: shared test data, timing assumptions, dependency on external state, or real intermittent bugs hiding as flakes. I fix or delete, never leave a permanently skipped test rotting. Longer term I add a flake budget and make test data creation isolated per run so one test can never poison another.

Frequently Asked Questions

What are the most common API testing interview questions?

The difference between API and UI testing, the meaning of status code families, 401 vs 403, what you validate beyond a 200, how you test authentication and rate limiting, and how you keep tests independent. Scenario questions about stale data and duplicate records are also very common.

How do I answer status code questions in an interview?

Reason from behavior to code rather than reciting a list. Explain the families (2xx success, 3xx redirect, 4xx client error, 5xx server error), then give a concrete example such as 201 with a Location header after a successful POST. Always be ready to justify your choice.

What is the difference between authentication and authorization in API testing?

Authentication proves who you are, tested with valid, missing, and expired tokens expecting 200 and 401. Authorization proves what you are allowed to do, tested by giving a valid token a forbidden action and expecting 403. Confusing the two is a common red flag.

Do I need to know a specific tool to pass an API testing interview?

You should be fluent in at least one (Postman, REST Assured, Playwright, or a code library), but the concepts matter more. Interviewers care that you understand HTTP, contracts, and failure modes; the tool is just how you express that understanding.

How do I explain schema validation to an interviewer?

Describe it as validating the response against the contract in executable form. It catches new required fields, changed types, and removed fields in a single assertion, acting as an early warning for backward-incompatible changes, while you still assert specific business values for your scenario.

How should I answer a scenario question I have never seen before?

Do not rush to an answer. Decompose the system into layers, state your assumptions, and describe how you would isolate each layer to find the fault. Interviewers grade the reasoning process far more than the final guess.