50 API Testing Interview Questions and Answers

API testing interviews are more predictable than most testing interviews, because there’s a fixed body of knowledge behind them: HTTP, REST conventions, auth, a few tools, and a way of thinking about what could go wrong with a request. This page covers the 50 questions that come up most, grouped from basics to scenarios, with answers at two levels where it matters: what a manual tester or fresher should say, and what an SDET or automation engineer is expected to add.

The short answer: API testing interviews cover five areas:

• HTTP and REST basics: methods, status codes, headers, idempotency, PUT vs PATCH.
• What to test: functional, negative, contract, security, performance, and how you’d test a specific endpoint.
• Authentication: basic, API keys, bearer tokens, OAuth 2.0, JWT.
• Tools and automation: Postman, REST Assured, pytest, Playwright, framework design, running in CI.
• Scenarios: a flaky test, a production bug the tests missed, an endpoint with no docs.

A strong answer names the concept, gives one concrete example, and says how you’d verify it.

HTTP and REST basics

1. What is an API, and why test it separately from the UI?

An API is the contract between a client and a server: which requests the server accepts and what it returns. You test it separately because API tests are faster (no browser), more stable (no locators), run earlier (before the UI exists), and find logic and data bugs the UI hides. Most of the business rules live behind the API; the UI just displays the result.

2. What’s the difference between REST and SOAP?

REST is an architectural style: resources at URLs, standard HTTP methods, usually JSON, stateless. SOAP is a protocol: XML envelopes, a WSDL contract, its own error format, and built-in standards for security and transactions. You’ll mostly test REST; SOAP still appears in banking, insurance and older enterprise systems.

3. Explain the HTTP methods and when each is used.

• GET reads a resource. No body, safe, idempotent, cacheable.
• POST creates a resource or triggers an action. Not idempotent: two POSTs may create two records.
• PUT replaces a resource entirely. Idempotent: sending the same PUT twice leaves the same state.
• PATCH partially updates a resource. Should be idempotent in practice but isn’t guaranteed.
• DELETE removes a resource. Idempotent: deleting twice leaves it deleted (though the second call may return 404).
• HEAD is GET without the body; OPTIONS returns allowed methods, used in CORS preflight.

4. What does idempotent mean, and why does it matter for testing?

An idempotent request produces the same server state no matter how many times you send it. GET, PUT and DELETE should be; POST usually isn’t. It matters because clients retry on timeouts. Test: send the same PUT twice and confirm one record with the final values; send the same POST twice and confirm the API either creates two records (documented) or rejects the duplicate with 409 or an idempotency key.

5. What’s the difference between PUT and PATCH?

PUT sends the whole resource and replaces it; a missing field becomes null or default. PATCH sends only the fields to change. Test for PUT: omit a field and confirm it’s cleared. Test for PATCH: send one field and confirm every other field is untouched. Interviewers ask this because many APIs implement PUT as PATCH, and that’s a bug worth finding.

6. Which status codes should you know, and what’s the difference between 401 and 403?

The full list is in the FAQ below. The distinction that gets asked: 401 Unauthorized means you’re not authenticated (no token, expired token). 403 Forbidden means you are authenticated but not allowed to do this (a normal user calling an admin endpoint). A well-designed API returns 401 for a missing token and 403 for a valid token with the wrong role. Testing both is one of the fastest ways to find authorisation bugs.

7. What’s the difference between 400 and 422?

Both are client errors. 400 Bad Request is for malformed input: invalid JSON, wrong content type. 422 Unprocessable Entity is for well-formed input that fails validation: a valid JSON body with an email that isn’t an email. Many APIs use 400 for both; ask which convention the team follows and test that it’s consistent.

8. What are HTTP headers, and which ones do you check in tests?

Headers carry metadata about the request or response. In requests: Content-Type, Accept, Authorization, and custom headers like X-Request-ID. In responses: Content-Type (assert it’s application/json), Cache-Control, ETag, Location (after a 201), rate-limit headers (X-RateLimit-Remaining), and security headers (Strict-Transport-Security, X-Content-Type-Options).

9. What does stateless mean in REST?

Each request carries everything the server needs; the server doesn’t remember previous requests. Authentication travels in every request as a token. Test: make request two without request one and confirm it works (or fails for the right reason, not “session not found”).

10. What’s the difference between path parameters, query parameters, and body?

Path parameters identify a resource: /users/42. Query parameters filter, sort or paginate: /users?role=admin&page=2. The body carries data to create or update. Test: a path parameter that doesn’t exist (404), a query parameter with an invalid value (400 with a clear message), and a body with an extra unknown field (ignored or rejected, but consistently).

What to test

11. What do you check in an API response?

Status code, response body (structure and values), headers, response time, and side effects (was the record actually created in the database, was the email queued). Freshers usually list the first two; interviewers want to hear the last three.

12. What types of API testing are there?

• Functional: does the endpoint do what the spec says.
• Negative: invalid input, missing fields, wrong types, boundary values.
• Contract: does the response match the agreed schema (OpenAPI, Pact).
• Integration: does the API work with the services and databases behind it.
• Security: auth, authorisation, injection, rate limiting, data exposure.
• Performance: response time under normal and peak load.
• Reliability: behaviour on timeouts, retries, partial failures.

13. How would you test a login API?

Manual tester answer: “Positive: valid username and password returns 200 with a token. Negative: wrong password returns 401 with a generic message that doesn’t reveal whether the username exists. Missing fields return 400. Locked account returns 403 or 423. SQL injection in the username field returns 400, not 500. Rate limiting kicks in after N failed attempts. The token expires after the documented time. Password isn’t returned in any response and isn’t logged.”

SDET answer adds: “I’d automate the positive and top negative cases as a smoke suite that runs on every deploy, put the security cases (injection, rate limiting, enumeration) in a nightly suite, and assert the response schema against the OpenAPI spec so a field rename breaks the build. I’d also test that the token works on a protected endpoint and that a tampered token is rejected, because a login test that never uses the token is incomplete.”

14. How would you test a payment API?

Amount validation (zero, negative, more than two decimals, very large), currency codes, idempotency (the same payment request with the same idempotency key doesn’t charge twice), timeouts (what happens if the payment gateway doesn’t respond), partial failures (payment succeeded but order creation failed), refunds and reversals, and that card numbers never appear in logs or responses. Use the gateway’s sandbox and test cards; never real ones.

15. What boundary values would you test for a field that accepts 1 to 100?

0, 1, 2, 99, 100, 101, a negative number, a decimal, a string, null, an empty value, and a very large number (integer overflow). Also the field missing entirely.

16. How do you test an API with no documentation?

Capture real traffic from the app using the browser’s network tab or a proxy (Charles, mitmproxy, Fiddler), look for /swagger, /openapi.json or /docs endpoints, read the client code if available, and explore: send a valid request, then remove fields one at a time, change types, and note what the server accepts. Write it down as you go. The output of this exercise is the documentation.

17. What is contract testing, and how is it different from schema validation?

Schema validation checks a response against a structure (this field is a string, this one is required). Contract testing, with a tool like Pact, checks that what the consumer expects matches what the provider delivers, and it runs on both sides so a provider can’t break a consumer without a test failing. It’s how teams with many microservices avoid integration testing everything together.

18. How do you test pagination?

First page, last page, a page beyond the last (empty result or 404, but documented), page size at its limit and over, page size zero, and consistency: the same item shouldn’t appear on two pages, and adding an item mid-scan shouldn’t skip another. For cursor-based pagination, test that an invalid or expired cursor returns 400.

19. How do you test rate limiting?

Send requests until you get 429, check the Retry-After and X-RateLimit-* headers are present and accurate, confirm the limit resets when it should, and confirm limits are per-user or per-key rather than global (one user shouldn’t be able to lock out another).

20. How do you test API versioning?

Call the same resource on /v1 and /v2 and confirm the documented differences, confirm v1 still works after a v2 deploy, and check that an unsupported version returns a clear 404 or 400 rather than falling through to a default.

Authentication and security

21. What authentication methods have you tested?

Basic auth (username:password base64 in the header, only over HTTPS), API keys (in a header, never in the URL), bearer tokens (usually JWTs), OAuth 2.0 (authorisation code flow for users, client credentials for services), and session cookies. For each, the tests are the same shape: valid credential works, missing is 401, invalid is 401, expired is 401, valid but wrong scope or role is 403.

22. What is a JWT, and what would you test about it?

A JSON Web Token has a header, a payload (claims like user ID, role, expiry) and a signature. Tests: an expired token is rejected; a token with a modified payload (change role to admin) is rejected because the signature no longer matches; a token signed with the wrong key is rejected; the alg: none attack is rejected; sensitive data isn’t in the payload (it’s only base64, not encrypted).

23. Explain OAuth 2.0 in one minute.

A user authorises an app to act on their behalf without sharing their password. The app redirects the user to the authorisation server, the user logs in and consents, the server returns an authorisation code, the app exchanges it for an access token (and usually a refresh token), and uses the access token on API calls. Tests: token exchange with a reused code fails, refresh works and rotates, revoked tokens stop working, scopes limit what the token can do.

24. What security issues do you look for in an API?

Broken authorisation (user A reading user B’s data by changing an ID, called IDOR), missing auth on an endpoint, excessive data in responses (returning the whole user object including the password hash), injection (SQL, NoSQL, command), mass assignment (sending "is_admin": true in a signup body and having it honoured), verbose error messages with stack traces, missing rate limits, and secrets in URLs or logs. The OWASP API Security Top 10 is the standard list; be able to name three.

25. How do you handle secrets in an automation suite?

Environment variables or a secrets manager, never in the repo. Separate credentials per environment. In CI, secrets are injected at run time and masked in logs. Tokens are fetched at suite start and refreshed if they expire mid-run.

Tools and automation

26. Which API testing tools have you used, and when would you pick each?

• Postman / Bruno: exploration, manual testing, sharing collections with developers.
• curl: quick checks, reproducing a bug in a bug report.
• REST Assured (Java), pytest + requests / httpx (Python), Playwright API (JS/TS), SuperTest (Node): automation in the team’s language.
• Karate: BDD-style API tests when the team wants readable specs.
• Newman: running Postman collections in CI.
• WireMock / MockServer / Prism: mocking dependencies.
• Pact: contract testing.
• k6 / JMeter / Locust: load.

Pick automation in the language the developers use so they’ll maintain it with you.

27. How do you structure an API automation framework?

Fresher answer: “Separate the test data, the request builders and the assertions. Keep a base URL and credentials per environment in a config file. Group tests by endpoint or feature. Tag tests as smoke, regression or nightly.”

SDET answer: “Layers: a thin HTTP client wrapper (logging, retries, auth injection), a service layer with one class per API resource exposing typed methods (users.create(payload)), test data builders or factories with sensible defaults, schema files for response validation, and the tests themselves, which read like the spec. Config per environment via environment variables. Tests are independent and create their own data, with cleanup in teardown. Parallel-safe by default. Reporting with Allure or the framework’s HTML report, and every failure logs the full request and response so nobody has to re-run to debug.”

28. How do you make API tests independent of each other?

Each test creates the data it needs (usually via the API itself or a direct DB seed), uses unique identifiers (a timestamp or UUID suffix), and cleans up after itself. No test depends on a previous test having run. This is what makes parallel execution possible.

29. What is data-driven testing, and how do you do it for APIs?

Running the same test with many inputs from a table or file. In pytest that’s @pytest.mark.parametrize; in JUnit it’s @ParameterizedTest; in Postman it’s a CSV with the collection runner. Use it for validation rules: one test, twenty rows of invalid emails, each with the expected error message.

30. How do you validate a JSON response?

Three levels: specific values (response.json()["status"] == "active"), structure against a JSON Schema or the OpenAPI spec, and negative structure (no unexpected fields, no password key). Libraries: jsonschema in Python, json-schema-validator with REST Assured, Ajv in JavaScript.

31. How do you mock a dependency?

If the API you’re testing calls a third-party service (payment gateway, email, another microservice), point it at a mock (WireMock, MockServer, Prism from the OpenAPI spec) that returns controlled responses, including failures and slow responses. That’s how you test “the gateway timed out” without waiting for it to happen.

32. How do you run API tests in CI?

A stage in the pipeline after deploy to a test environment: smoke suite on every merge (a few minutes), full regression nightly or on release branches. Fail the build on any smoke failure. Publish the report as a build artefact. Secrets from the CI’s secret store. If the suite takes more than ten minutes, shard it.

33. How do you handle a flaky API test?

First find out why: timing (the record isn’t there yet because of async processing), shared data (two tests using the same user), environment (a dependency that’s sometimes down), or a real intermittent bug. Fix the cause: poll with a timeout instead of sleeping, isolate data, mock the dependency, or file the bug. Don’t add retries as the first fix; a retry hides the bug the test was written to find.

34. What’s the difference between sleep and polling in a test?

sleep(5) waits five seconds every time, whether the result is ready in one second or six. Polling checks every half-second until the condition is true or a timeout is hit. Polling is faster on average and more reliable at the tail. Any test that has a sleep in it is a candidate for review.

35. How do you test asynchronous APIs?

For a job-style API: POST returns 202 with a job ID, then poll a status endpoint until it’s completed or failed, with a timeout, then assert the result. For webhooks: register a test endpoint (a local receiver or a service like a request bin), trigger the event, and assert the webhook arrived with the right payload and signature within the SLA. For message queues: consume from the queue in the test.

Advanced

36. What is CORS, and how does it show up in API testing?

Cross-Origin Resource Sharing is the browser’s rule about which origins may call the API. It’s enforced by the browser, not the server, so API tests from a script don’t hit it; the UI does. Test: an OPTIONS preflight returns the right Access-Control-Allow-Origin, and it’s not * on an authenticated API.

37. What are ETags and conditional requests?

An ETag is a version identifier in a response header. A client sends it back with If-None-Match; if the resource hasn’t changed the server returns 304 with no body. For updates, If-Match prevents overwriting someone else’s change (returns 412 if the ETag is stale). Test both. Optimistic concurrency bugs are common and expensive.

38. How do you test file upload and download endpoints?

Upload: valid file, empty file, oversized file (413), wrong type (415), a file whose extension doesn’t match its content, filename with path traversal (../../etc/passwd). Download: correct Content-Type and Content-Disposition, correct bytes (compare a hash), range requests if supported, and that user A can’t download user B’s file.

39. What’s different about testing GraphQL?

One endpoint, POST for everything, and the client picks which fields it wants. Status code is usually 200 even for errors; the errors are in the body. Tests: query depth and complexity limits (a nested query that would bring the server down), field-level authorisation (a user can query the users type but not the email field of other users), introspection disabled in production, and N+1 behaviour under a list query.

40. What’s different about testing gRPC?

Binary protocol over HTTP/2 with a .proto contract, so the contract is enforced by code generation. Tests use a generated client, check status codes from the gRPC set (OK, INVALID_ARGUMENT, NOT_FOUND, PERMISSION_DENIED, UNAVAILABLE), and test streaming: server streams, client streams, and cancellation mid-stream. Tools: grpcurl for exploration, the language’s generated stubs for automation.

41. How do you performance test an API?

Define the target first (p95 under 300 ms at 500 requests per second, say). Use k6, JMeter or Locust to ramp load, measure latency percentiles and error rate, and watch the server (CPU, memory, DB connections). Test the realistic mix of endpoints, not one endpoint in isolation. Run against an environment sized like production or the numbers mean nothing.

42. What is API mocking versus API virtualisation?

Mocking returns canned responses for a specific test. Virtualisation is a longer-lived simulated service, often recorded from the real one, that a whole team uses when the real dependency is unavailable, expensive or rate-limited. Same idea, different scale.

Scenario questions

43. A test passes locally and fails in CI. What do you check?

Environment differences (base URL, credentials, feature flags), data (CI environment is empty or has different seed data), timing (CI is slower; a race the local run never loses), parallelism (two tests sharing a user), and network (a dependency not reachable from CI). Read the CI logs for the actual request and response before guessing.

44. A bug reached production that your API tests didn’t catch. What do you do?

Reproduce it with a request, write the test that would have caught it, and confirm the test fails on the old build and passes on the fix. Then ask why the gap existed: was it an untested endpoint, an untested combination, an environment difference, or a test that was skipped? Fix the category, not just the instance. Share the finding without blame.

45. The developer says the API is “done” but there’s no spec. How do you start?

Ask for the acceptance criteria or the ticket, capture the requests the UI actually makes, write a one-page description of what you think the endpoint does, and get the developer to correct it. That page becomes the test plan and, often, the spec.

46. An endpoint returns 200 with {"success": false} on errors. Is that a bug?

It’s a design smell and worth raising: clients and monitoring rely on status codes, and a 200 hides failures from every tool that counts errors. But if it’s a documented convention of an existing API, it’s not something you’ll change in a sprint; test the behaviour that exists and note the risk.

47. How would you test an API that sends emails?

Point the email service at a capture tool (Mailhog, Mailtrap, or a mock SMTP server), trigger the action, and assert the email exists, is addressed correctly, and has the expected subject and body. Never let test runs send real email.

48. Your suite takes 40 minutes. How do you cut it down?

Measure first: which tests are slow and why. Then: run in parallel, replace sleeps with polling, seed data via the DB instead of many API calls, mock slow dependencies, split smoke from regression, and remove duplicated coverage. Forty minutes usually comes down to under ten with parallelism and sleep removal alone.

49. How do you decide what to automate?

Automate what runs often and is stable: smoke paths, validation rules, auth, regression for fixed bugs. Explore manually what’s new, complex, or changing daily. Don’t automate one-off checks or anything that changes with every sprint until it settles.

50. How do you explain the value of API tests to a manager who only sees UI tests?

Numbers: API tests run in seconds instead of minutes, fail for real reasons instead of locator changes, and can run before the UI exists. Show the last three bugs the API suite caught that the UI suite would have missed, and the maintenance time saved. Then show the UI suite shrinking to the handful of end-to-end journeys that actually need a browser.

Preparing the night before

1. Re-read the status codes and the 401/403, 400/422 and PUT/PATCH distinctions. They’re asked in nearly every interview.
2. Pick one API you’ve actually tested and be ready to walk through it in detail: what it did, what you tested, what you found, what you automated.
3. Have one framework structure you can draw on a whiteboard.
4. Have one flaky-test story and one production-bug story, both with what you changed afterwards.
5. Open Postman or Bruno and send five requests to a public API (the GitHub API or JSONPlaceholder). Interviewers sometimes ask you to do it live.

Where Tailr fits

API testing roles vary a lot in what they want: some want Postman and exploratory skill, some want a Java framework, some want contract testing and CI. The job listing tells you which. Tailr tailors your resume to the specific listing you’re viewing, so the tools and testing types the role actually names are the ones your resume leads with, and the interview questions above are the ones you’ve prepared for. Pair it with best tools for QA and software testing for the tooling side, and with 40 behavioral interview questions with sample answers for the non-technical round. Try Tailr to line the resume up with the role before the technical round.

Related guides

• 50 Manual Testing Interview Questions and Answers
• What Is Software Testing? Types, Levels and Methods Explained
• What Is API Testing? Types, Tools and How to Start
• QA Engineer vs. SDET: Differences, Salary and Which to Choose
• Top QA Interview Questions (and How to Answer Them)

Conclusion

API testing interviews reward people who understand HTTP properly, can turn an endpoint into a list of tests in a minute, know the difference between testing and automating, and have real stories about what broke and what they changed. Know the status codes cold, be able to test a login endpoint out loud, have one framework design you can defend, and bring one flaky-test and one production-bug story. That covers most of the 50 above and almost everything an interviewer will improvise.