API Testing Interview Questions: 7 Critical Topics Every SDET Must Master (2026)

It is 11:47pm. You have been staring at the same sentence in the job spec for the last twenty minutes: "Experience designing and implementing automated API test suites at scale." Your CV says you have that experience. You have written hundreds of API tests — Postman collections, REST Assured suites, a few Playwright API tests when the UI tests needed setup data. You know what a 200 means and what a 404 means and you can write a fetch() call in your sleep. But staring at those nine words at 11:47pm, you suddenly realise you do not have a structured answer to the question that is coming: "Walk me through how you would design an API test strategy for a microservices architecture with 23 services. What would you test at each layer? What would you mock? What would you contract-test? And how would you prevent the test suite from becoming a bottleneck in CI/CD?" Your Postman collections are not going to answer that. Neither are your REST Assured scripts. The panel is not testing whether you can make an HTTP call — they are testing whether you can think about API testing as an architectural discipline, not a collection of scripts.

Mitchell has watched this exact gap claim otherwise strong SDET candidates across 20 years at HMRC, the Ministry of Defence, Nationwide, Accenture, Asda, the Co-op, and BT. The candidate who can write a Playwright E2E test for a 12-step checkout flow freezes when asked "how do you test an API endpoint that depends on three upstream services — all of which are flaky in the test environment?" The candidate who has been testing APIs for five years cannot explain the difference between contract testing and integration testing — or why you need both. And the candidate who says "I test the happy path, the error cases, and the edge cases" cannot articulate what specifically they would test on a POST /payments endpoint — the request validation, the idempotency, the compensating transactions, the concurrency behaviour, and the response contract — in the structured, systematic way that separates someone who has tested APIs from someone who has architected API testing. The gap is not knowledge of HTTP methods — every candidate knows GET, POST, PUT, DELETE, and PATCH. The gap is architectural thinking about APIs: the testing pyramid applied to the API layer, the distinction between testing the implementation and testing the contract, the strategy for testing stateful API workflows, the approach to testing APIs that depend on third-party services, and the integration of API tests into CI/CD pipelines in a way that accelerates delivery rather than blocking it.

Here is what keeps Mitchell's SDET candidates awake — and what should keep you awake: in 2026, API testing is no longer a checkbox on the SDET job description. It is the backbone of modern test automation. Every microservice, every mobile app, every single-page application communicates through APIs. Every bug that reaches production in 2026 — the payment that was charged twice, the user data that was silently dropped, the integration that broke after a deployment — exists at an API boundary. And every senior SDET interview now probes whether you can design API testing that catches those bugs before they reach users — not just write assertions against response bodies. Can you explain when to use contract testing (Pact) instead of integration testing? Can you design an API test data strategy that handles stateful workflows without polluting shared environments? Can you discuss the trade-offs between testing APIs through the UI, through direct HTTP calls, and at the service layer — and when each is appropriate?

The SDET Interview Coach iOS app — with 800+ questions across 32 topics, Claude-graded mock interviews from Junior to Lead, and dedicated modules on API testing, REST Assured, Postman, contract testing, and API test architecture — gives you the structured practice to discuss API testing with the precision of someone who has designed an API test strategy for 23 microservices, for £4.99 per month. And the AI Test Automation Playbook (£9.99) includes a complete chapter on API test automation at scale — covering contract testing, test data factories, and CI/CD integration. Do not walk into your interview knowing only how to call an endpoint. Walk in knowing how to design the testing architecture that makes every API call trustworthy.

What Interviewers Are Actually Testing When They Ask About API Testing — It Is Never "Do You Know HTTP?"

When an interviewer asks "how do you approach API testing?", they are not checking whether you know the difference between GET and POST. A candidate who says "I test every endpoint with valid and invalid inputs" has demonstrated they can write test cases — and also signalled that they have never been responsible for an API test suite at scale. What the interviewer is actually testing is whether you can think about APIs as a system of contracts, dependencies, and workflows — and design a testing approach that validates correctness at every layer of the API stack.

The one-sentence answer that anchors every strong API testing interview response: "API testing is not about making HTTP calls and checking status codes — it is about designing a layered testing strategy (service, contract, workflow) that validates correctness at every level of the API stack, catches integration-breaking changes before deployment, handles test data at scale, and integrates into CI/CD pipelines in a way that accelerates delivery; the skill interviewers are testing is not whether you can call an endpoint, but whether you can architect the testing system that makes every API call trustworthy."

The 7 Critical API Testing Topics — With Interview Questions and Model Answers

Here are the topics that Mitchell has both tested candidates on and been tested on across 20 years of SDET interviews — each with the question format and the answer structure that demonstrates genuine API-testing maturity.

Topic 1: HTTP Methods and Status Codes — Beyond the Basics

Interview question: "Explain the difference between PUT and PATCH — and when you would use each in API testing. Also, what does a 409 status code mean and when would you test for it?"

What the interviewer is testing: They are checking whether you understand REST semantics beyond "GET reads and POST creates" — and whether you design tests that verify the API's behaviour matches its HTTP contract. A candidate who says "PUT replaces the whole resource and PATCH updates part of it" has given a textbook answer. A candidate who goes further demonstrates practical testing experience.

Model answer: "PUT is idempotent — sending the same PUT request multiple times produces the same result. It replaces the entire resource at the given URI. If I PUT { "name": "Alice", "email": "alice@test.com" } to /users/42, the user with ID 42 now has exactly those fields — any other fields (like 'phone') are removed or set to defaults. PATCH applies a partial update — PATCH { "email": "new@test.com" } to /users/42 changes only the email field. The testing implications: for PUT, I test that omitted fields are reset — if the user had a phone number before the PUT and the PUT body does not include a phone number, is the phone number cleared? That is often a bug because developers implement PUT as a partial update, violating the HTTP spec. For PATCH, I test that only the specified fields change — if I PATCH the email, does the phone number remain unchanged? I also test PATCH with an empty body, with an invalid field name, and with a field the user is not allowed to modify (like 'role'). A 409 Conflict means the request cannot be completed because of a conflict with the current state of the resource — the classic example is two users editing the same document simultaneously. I test for 409 in scenarios like: creating a resource with a duplicate unique identifier, updating a resource that has been modified since you last read it (optimistic locking), and trying to delete a resource that is referenced by another resource (foreign key constraint). The principle: HTTP status codes are part of the API's contract. My tests verify that the API returns the correct status code for every scenario — including the ones developers often miss, like 409 Conflict, 422 Unprocessable Entity (semantic errors, not syntax errors), and 429 Too Many Requests (rate limiting)."

Topic 2: REST vs GraphQL — Testing Strategies for Both

Interview question: "How does your API testing approach differ for REST APIs versus GraphQL APIs? What are the unique testing challenges of GraphQL?"

What the interviewer is testing: They want to know whether you treat GraphQL as "just another API" — or whether you understand that GraphQL's flexibility creates testing challenges that REST does not have, and have adapted your approach accordingly.

Model answer: "GraphQL changes the testing surface in three fundamental ways. First — Over-fetching prevention becomes under-fetching validation: in REST, you test that the endpoint returns the correct fields. In GraphQL, the client specifies which fields it wants — so you test that every field in the schema works, that nested queries resolve correctly, and that requesting non-existent fields returns clear errors. The challenge shifts from 'does this endpoint return the right data?' to 'does every query pattern consumers might use return correct data?' Second — N+1 problem becomes a testing concern: GraphQL resolvers can trigger N+1 database queries — fetching a list of users, then for each user fetching their orders, then for each order fetching its items. In REST, this would be three separate endpoints and three separate tests. In GraphQL, a single query can trigger hundreds of database calls. I test for N+1 by running queries that touch multiple nested types and verifying that the database query count is reasonable — using DataLoader or a similar batching mechanism. Third — Error handling is partial: in REST, an error means the entire request failed. In GraphQL, a query can return partial data with partial errors — three users loaded successfully but the fourth user's orders failed to resolve. I test that partial errors are surfaced correctly in the response (in the 'errors' array), that the successful data is still returned, and that the HTTP status code is 200 (because the query itself succeeded, even if some fields errored) — which is counterintuitive for testers used to REST. The unique GraphQL testing challenge: the number of possible queries is effectively infinite. In REST, you test 20 endpoints. In GraphQL, you test the schema — all types, all fields, all arguments, all mutations, all subscriptions — and then a representative set of query patterns that consumers actually use."

Topic 3: API Mocking and Stubbing — When, Why, and How

Interview question: "Your API depends on three upstream services that are frequently unavailable in the test environment. How do you design your API tests to be reliable despite these dependencies?"

What the interviewer is testing: They are testing whether you have solved the "flaky test environment" problem that plagues every microservices architecture — or whether you accept test failures as inevitable.

Model answer: "I use a layered mocking strategy — different tools for different layers of the API test suite. For service/component tests: I mock external dependencies using WireMock or MockServer. WireMock runs as a standalone HTTP server that responds to requests with pre-configured responses. I define stubs that match on request path, method, headers, and body patterns: 'When you receive a GET to /users/42 with Accept: application/json, respond with 200 and this body.' WireMock verifies that expected requests were made and captures unmatched requests as test failures. For frontend API testing with Playwright or Cypress: I use Mock Service Worker (MSW). MSW intercepts requests at the network level in the browser — the frontend makes a real fetch() call, MSW intercepts it in the service worker, and returns a mock response. The key advantage over jest.mock: the frontend code runs unchanged, and MSW catches when the frontend makes requests that do not match any handler — revealing integration gaps that jest.mock hides. For contract testing: I use Pact — it generates mock servers from consumer-defined contracts, so the consumer tests run against a Pact mock that exactly matches the provider's expected behaviour. The principle: mock at the boundary of your control. Mock services owned by other teams so your tests are not blocked by their instability. Do not mock your own database or business logic — that is where the bugs live. And always run a subset of tests against the real dependencies periodically (a 'contract validation' suite in CI) to catch drift between your mocks and reality. At BT, Mitchell's team used this layered strategy: WireMock for Java service tests, MSW for React frontend tests, and Pact for cross-team contract validation. The result: test suite reliability went from 73% (due to upstream flakiness) to 99.2% — without losing the confidence that comes from testing real integrations."

Topic 4: API Test Automation Frameworks — REST Assured, Postman, Playwright, Supertest, and Karate

Interview question: "Walk me through your API test automation tool stack. Why those tools, and what are their limitations?"

What the interviewer is testing: They are checking whether you have opinions about tools — informed by real-world use — or whether you just use whatever was already set up when you joined the team. The strongest candidates can discuss trade-offs, not just feature lists.

Model answer: "My tool selection depends on the team's tech stack and the testing requirement. REST Assured is my default for Java/Kotlin projects — it has a fluent, BDD-style API that reads like English: `given().queryParam("status", "active").when().get("/users").then().statusCode(200).body("size()", greaterThan(0))`. Its strength is that it lives in the same codebase as the application — the same build tool, the same CI pipeline, the same code review process. Its limitation is the Java verbosity — complex test scenarios with multiple API calls become visually dense. For JavaScript/TypeScript projects, I use Playwright's API testing or Supertest. Playwright's `request` fixture gives you HTTP client capabilities with the same test runner as your UI tests — one framework, one test report, one CI integration. Supertest is lighter-weight and pairs well with Jest — `await request(app).post('/users').send({ name: 'Alice' }).expect(201)`. For exploratory testing and collaboration with non-developers, Postman is irreplaceable — its collection runner, environment variables, and pre-request scripts make it accessible to QA engineers who do not write production code. But for CI/CD integration, I export Postman collections to Newman (the CLI runner) or migrate critical tests to code-based frameworks — because UI-maintained Postman tests drift from the codebase over time. For teams that want a single tool for API and UI testing with low code, Karate is compelling — it uses Gherkin syntax with built-in HTTP, JSON, and assertion capabilities. Its limitation is that it is a DSL, not general-purpose code — complex test logic (dynamic data generation, multi-step state machines) becomes awkward. The principle: the right tool is the one the team will maintain. A perfectly architected REST Assured suite that only you can update is worse than a Postman collection the whole team contributes to."

Topic 5: API Performance Testing — Response Time, Throughput, and Load Profiles

Interview question: "How would you approach API performance testing? What metrics matter and how would you integrate performance testing into CI/CD?"

What the interviewer is testing: They want to know whether you treat performance testing as a separate activity (run before release) or an integrated part of the testing pipeline (run on every commit) — and whether you understand which metrics signal real problems versus noise.

Model answer: "I approach API performance testing in three tiers. Tier 1 — Baseline tests in CI (every commit): run a small set of performance assertions against critical endpoints — login, search, checkout. Assert that p95 response time is under 200ms and that the endpoint can handle 50 concurrent requests without errors. These are not load tests — they are regression tests for performance. If a commit causes the search endpoint to jump from 80ms to 400ms, the CI pipeline fails. Tools: k6 or Artillery, which are scriptable and produce CI-friendly output. Tier 2 — Load tests (nightly or per-release): run realistic load profiles against the full API surface — ramp up from 0 to 1,000 virtual users over 5 minutes, sustain for 10 minutes, ramp down. Measure: response time percentiles (p50, p95, p99), throughput (requests/second), error rate, and resource utilisation (CPU, memory, database connections). The key insight: averages lie. A p50 of 50ms with a p99 of 5 seconds means 1% of users are experiencing terrible performance — and those are your highest-value users who trigger the complex queries. Always report percentiles. Tier 3 — Stress tests (before major releases): push the system until it breaks. Find the breaking point — at what throughput does the error rate exceed 1%? At what point do response times degrade non-linearly? This gives you a capacity-planning baseline and reveals the system's failure mode — does it degrade gracefully (slow responses) or fail catastrophically (500 errors)? For CI/CD integration: the performance test scripts live in the same repository as the application. k6 tests are JavaScript — they run alongside unit and integration tests. The CI pipeline runs baseline performance tests on every commit. Nightly builds run full load tests. The principle: performance testing that only runs before a release finds problems too late to fix without delaying the release. Shift performance testing left — make it part of the definition of done for every PR."

Topic 6: API Error Handling — Negative Testing Beyond 4xx and 5xx

Interview question: "Tell me about the most interesting API bug you found through negative testing. What was your approach?"

What the interviewer is testing: They are checking whether your negative testing is systematic or ad-hoc — and whether you understand that the most dangerous API bugs are not in the error-handling code, but in the absence of error handling entirely.

Model answer: "The most interesting API bug I found was at Nationwide, testing the mortgage-application API. The endpoint `POST /applications/{id}/submit` accepted the application and triggered a workflow: validate documents, run affordability check (external service), create mortgage offer. The happy path worked. The error paths I had tested: missing documents → 422, failed affordability → 422 with reason. The bug: the affordability-check API returned a 200 with an empty body — not a 4xx or 5xx — when the applicant had insufficient credit history for a definitive answer. Our API treated the 200 as 'passed' and proceeded to create a mortgage offer. The applicant received an offer letter for a mortgage they should not have been approved for. My negative-testing approach that found this: I do not just test status codes — I test response body correctness for every possible upstream response. For each upstream dependency, I enumerate every response it could theoretically return (not just the documented ones) and verify that our API handles each one correctly. Empty 200, 200 with unexpected structure, 200 with missing required fields, 200 with null values where non-null is expected, 200 with an error message in the body (some services return 200 with `{ "error": "..." }` instead of 4xx), 301 redirect, 503 with Retry-After header, and response after timeout (the upstream returns after our client timeout). The principle: test the integration, not just the interface. Your API's error handling is only as good as its handling of errors from the services it depends on — and those errors are rarely the ones documented in the upstream API spec."

Topic 7: API Testing in CI/CD — Speed, Parallelism, and Feedback Loops

Interview question: "Your API test suite takes 45 minutes to run. The team wants to run it on every PR but says that is too slow. How do you reduce the runtime without sacrificing confidence?"

What the interviewer is testing: They are testing whether you understand that test suite speed is a testing-architecture problem — not just an infrastructure problem — and whether you have practical strategies for making API tests fast enough for CI/CD.

Model answer: "I attack the 45-minute runtime on four fronts simultaneously. Front 1 — Test selection: not every PR needs every test. I use a risk-based selection strategy: if the PR changes the payments service, run the full payments test suite. Run a smoke-test subset (5 minutes) of other services' API tests to catch cross-service breakage. Run the full suite nightly. This alone cuts PR-test time from 45 minutes to 10-15 minutes. Tools: build-system plugins that map changed files to test suites, or custom scripts that use git diff to identify affected services. Front 2 — Parallelisation: most API tests are independent — they test different endpoints with isolated test data. Run them in parallel across multiple CI workers. A 45-minute suite split across 5 workers becomes 9 minutes — provided the test environment can handle the parallel load. The bottleneck is usually the database: if all workers write to the same database, they collide on test data. Solution: each worker gets its own database schema or uses transactions for isolation. Front 3 — Test data optimisation: the most common cause of slow API tests is test data setup that calls the API multiple times to create prerequisite entities. Replace multi-step setup with direct database inserts — instead of calling POST /users, POST /products, POST /orders, POST /order-items (four API calls), insert the test data directly into the database (one SQL script). This is 10-50x faster. The trade-off: you are testing against a database state that was not created through the API, so you might miss bugs in the creation endpoints. Mitigation: one test per entity type that tests the creation endpoint end-to-end; all other tests use direct inserts for speed. Front 4 — Mock external dependencies: if your API tests call third-party services (payment gateways, email providers, address validators), those calls add seconds per test and are unreliable. Mock them with WireMock in CI — the tests run in under a minute instead of 5+ minutes. Run a nightly contract-validation suite against the real dependencies to catch drift. The principle: test suite speed is a feature. A test that takes 60 seconds to run is a test that developers will skip. Design for speed from the start — fast tests get run, slow tests get ignored."

Common Mistakes SDET Candidates Make in API Testing Interviews

Mitchell has watched hundreds of candidates make the same API testing interview mistakes across 20 years at HMRC, the Ministry of Defence, Nationwide, and Accenture. Here are the five most common — and how to avoid them at 11:47pm before your interview.

The API Testing Tools Landscape in 2026 — What Interviewers Expect You to Know

The API testing tool ecosystem has matured significantly, and interviewers expect candidates to have informed opinions about the tools they use. Here is the landscape as of 2026 — with the trade-offs that matter in interviews.

Your API Testing Interview Preparation Checklist — Starting Tonight

You do not need to have tested 23 microservices to answer API testing questions well. You need to understand the concepts, have a structured testing framework, and be able to discuss trade-offs — not just tools. Here is the preparation plan:

1. Memorise the five-dimension framework: Request validation, business logic, state transitions, idempotency/concurrency, response contract. For every API endpoint an interviewer asks about, organise your answer around these five dimensions. It makes you sound like someone who tests systematically — not someone who lists test cases from memory.
2. Prepare your API testing pyramid explanation: Unit tests at the base (logic), service/component tests in the middle (API with mocked dependencies), contract tests at the integration boundary, and E2E workflow tests at the peak (critical paths only). Be ready to explain what you test at each layer and why.
3. Have a contract-testing answer ready: Explain the difference between contract testing and integration testing, describe the Pact consumer-provider workflow, and give at least one example of a bug that contract testing would catch that integration testing would miss.
4. Pick two tools and know their trade-offs: For example, REST Assured (enterprise standard, lives in codebase, Java verbosity) vs Playwright API testing (unified framework, TypeScript ecosystem, newer). Be able to explain why you would choose one over the other.
5. Prepare a CI/CD answer: How would you reduce a 45-minute API test suite to run on every PR? Test selection, parallelisation, data optimisation, and external dependency mocking. This is the question that separates SDETs from QA Automation Engineers.
6. Download the SDET Interview Coach app and complete the 2-minute onboarding assessment. Select the API testing topic area and your target seniority level. The app surfaces API testing questions calibrated to your interview — Junior candidates get foundational HTTP and REST questions, while Senior and Lead candidates face full API test architecture discussions including contract testing, test data strategy, and CI/CD integration. Each answer receives Claude-graded feedback on technical accuracy, completeness, and communication.
7. Run an API testing mock interview tonight. Answer the questions out loud — describing your five-dimension framework for a POST endpoint, explaining your API testing pyramid, discussing contract testing vs integration testing. The AI feedback will show you exactly where your API testing knowledge gaps are before the real interview exposes them.

The API testing question is not testing whether you can call an endpoint — it is testing whether you can design the testing architecture that makes every API call trustworthy, at scale, in CI/CD, across a microservices ecosystem. The candidates who walk into interviews in 2026 with a structured testing framework, a tool-selection rationale, and a contract-testing strategy are the ones who get offers over candidates who say "I test the happy path, error cases, and edge cases." API testing is an architectural discipline. Learn to think like an architect. Walk in ready.

For more on API mocking and stubbing, see our guide on WireMock API Mocking and Stubbing. For contract testing with Pact, see our guide on SDET Behavioural Interview Questions. For the complete SDET interview preparation roadmap, see our SDET Interview Preparation Plan 2026. And for daily structured practice with AI-graded feedback, download the SDET Interview Coach on iOS — £4.99/month with 800+ questions across 32 topics, including comprehensive API testing coverage from REST fundamentals to GraphQL schema testing and CI/CD pipeline integration. The AI Test Automation Playbook (£9.99) includes a complete chapter on API test automation at scale — the exact framework Mitchell used at HMRC, Nationwide, and Accenture to build API test suites that ran in under 10 minutes in CI/CD.

Test the contract. Mock the boundaries. Shift left. Walk in ready.