API Testing Interview Questions: 50+ Q&As with Examples (2026)

In this guide

1. Foundations: HTTP, REST, status codes
2. Functional and integration testing
3. Contract testing
4. API security testing
5. Performance and reliability
6. CI/CD and shift-left scenarios
7. Tools and platforms
8. Behavioral and scenario questions
9. API testing interview prep checklist
10. FAQ

Why interviews changed in 2026

A decade ago, an API testing interview was effectively a Postman quiz. Today the role expects candidates to design quality strategies, not click through requests. The figure below shows why: traditional pipelines push API checks late; modern API-first pipelines run them at PR time, with AI-generated coverage and contract gates.

A candidate who can talk fluently about both sides of that diagram — and articulate the migration path — will stand out. The questions below are organized to match.

1. Foundations: HTTP, REST, status codes

Q1. What is API testing in plain terms? A1. API testing validates the contract a service exposes — request and response shapes, status codes, business rules, performance, and security — without going through a UI. It is faster and more stable than UI testing because APIs are deterministic and machine-callable.

Q2. What is the difference between SOAP and REST? A2. SOAP is a protocol with strict messaging (XML, WSDL, SOAP envelopes). REST is an architectural style over HTTP using verbs and resources. SOAP enforces contracts via WSDL; REST relies on conventions and OpenAPI for the same.

Q3. List the HTTP methods and their semantics. A3. GET (safe, idempotent), POST (not safe, not idempotent), PUT (idempotent, replaces), PATCH (not safe, often idempotent, partial update), DELETE (idempotent), HEAD (like GET, headers only), OPTIONS (capabilities). Idempotent means repeated calls yield the same effect; safe means no server-state change.

Q4. What do the status code ranges mean? A4. 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. Memorize 200/201/204, 301/302/304, 400/401/403/404/409/422/429, 500/502/503/504.

Q5. Difference between 401 and 403? A5. 401 = no/invalid credentials. 403 = authenticated but not authorized for the resource. Mixing them is a frequent bug.

Q6. Difference between PUT and PATCH? A6. PUT replaces the whole resource. PATCH applies a partial change. PUT is always idempotent; PATCH can be designed to be (preferred) but is not required to be.

Q7. What is idempotency and why does it matter? A7. An idempotent operation produces the same effect regardless of how many times it runs. It matters for retries — a network glitch shouldn't double-charge a credit card. Use Idempotency-Key headers for non-idempotent operations like payments.

Q8. What is content negotiation? A8. Client and server agree on representation via headers — Accept, Content-Type, Accept-Language, Accept-Encoding. Tests must cover variants when an API supports multiple media types.

2. Functional and integration testing

Q9. What categories of API testing exist? A9. Functional, contract, integration, regression, performance/load, security, and end-to-end. Most teams start with functional and contract, then layer the others.

Q10. How do you design test cases for an endpoint? A10. From the OpenAPI spec: cover every status code listed, every parameter (boundary, missing, malformed), every authentication branch, every business rule expressed in the description, and the schema for each response. Add error envelopes and rate-limit responses.

Q11. What is a happy path versus a negative test? A11. Happy path = expected inputs producing the documented success response. Negative tests = malformed payloads, missing fields, wrong types, expired tokens, deleted resources. Coverage requires both.

Q12. How do you test pagination? A12. Hit page 1, page n, and beyond-the-end. Verify totals, cursor stability across writes, and that combining limit + cursor doesn't double-return rows. Watch for off-by-one errors at boundaries.

Q13. How do you test sorting? A13. Test stable sort under ties, ascending/descending, NULLs (first/last), and combined with filters and pagination. The composition of pagination + sort + filter is a classic bug source.

Q14. How do you test filtering and search? A14. Boundary values, case sensitivity, regex injection, empty result, and SQL/NoSQL injection if filters land near a query layer.

Q15. What is end-to-end API testing? A15. A chain of API calls representing a user journey — sign up, create order, pay, fulfill. Asserts state transitions across services, not just one endpoint.

3. Contract testing

Q16. What is contract testing? A16. Validating that a producer's responses match the schema and examples consumers expect. It catches integration drift before deploy. Tools: Pact, Schemathesis, Total Shift Left.

Q17. Producer-driven vs consumer-driven contract testing — the difference? A17. Producer-driven publishes the spec; consumers verify against it. Consumer-driven publishes consumer expectations as pacts; producers verify they meet every consumer's needs. CDC catches expectations the spec misses.

Q18. What is schema validation in API testing? A18. Asserting every response matches the OpenAPI/JSON Schema for that operation — required fields, types, formats, enum values, additional-properties policy. Skipping schema validation is the #1 source of silent contract drift.

Q19. How does OpenAPI relate to contract testing? A19. OpenAPI is the contract. Contract tests validate runtime responses against it. AI generators read it to produce a starting test suite. Mock servers serve it.

Q20. What is contract drift? A20. When deployed code returns responses that no longer match the published spec — usually because the spec wasn't updated when code changed. Contract gates in CI prevent it.

Q21. How do you contract-test a GraphQL API? A21. The schema (SDL) is the contract. Use schema linters (graphql-inspector), assert that resolvers don't return extra fields, and snapshot persisted queries.

4. API security testing

Q22. List the OWASP API Security Top 10 (2023). A22. Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management, Unsafe Consumption of APIs.

Q23. How do you test BOLA (Broken Object Level Auth)? A23. Authenticate as user A, request resources owned by user B by ID. The API must reject. Test with random IDs, off-by-one IDs, and IDs from other tenants.

Q24. How do you test authentication flows? A24. Cover token expiration, refresh, revocation, replay, malformed tokens, wrong audience/issuer, and clock skew. For OAuth, test PKCE, state, and consent.

Q25. How do you prevent injection in APIs? A25. Parameterized queries server-side. In testing: send SQL/NoSQL injection payloads in every string field and confirm 4xx, not 200.

Q26. What is rate limiting and how do you test it? A26. Throttling per identity over time. Test by exceeding limits and asserting 429 Too Many Requests, Retry-After header presence, and that legitimate retries are honored.

Q27. How do you test CORS? A27. Send Origin headers from allowed and disallowed origins. Verify Access-Control-Allow-Origin reflects only allowed values. Don't accept * for endpoints that expose credentials.

Q28. What is JWT and what should tests cover? A28. Signed token with claims. Tests must cover expiration, signature tampering, algorithm swap (none, RS256→HS256), and audience/issuer validation.

5. Performance and reliability

Q29. Difference between load, stress, and soak testing? A29. Load = expected peak. Stress = beyond peak to find breaking point. Soak = sustained load over hours/days to find leaks.

Q30. What metrics matter in API performance testing? A30. p50/p95/p99 latency, throughput (req/s), error rate, saturation of upstream resources (CPU, DB), and time-to-first-byte.

Q31. What tools do you use for performance testing? A31. k6, Gatling, JMeter, Locust. k6 is JS-scripted and CI-friendly; Gatling is Scala/Java; JMeter has the broadest protocol support.

Q32. How do you test API resilience? A32. Inject failures — kill upstream services, latency, partial responses, network partitions. Verify timeouts, retries with backoff, and graceful degradation (circuit breakers).

Q33. What is chaos engineering for APIs? A33. Deliberately injecting failures in production to validate resilience. Tools: Chaos Mesh, Gremlin, Litmus.

6. CI/CD and shift-left scenarios

Q34. What does shift-left API testing mean? A34. Moving API validation into the earliest stages of the SDLC — design, IDE, pre-commit, PR — instead of staging or post-release. See our shift left API testing guide.

Q35. Walk me through a CI pipeline for API testing. A35.

Eight stages: commit, spec lint, AI test generation, contract validation, security scan, performance smoke, quality gate, release. Failures at any stage block the merge.

Q36. What is a quality gate? A36. A pass/fail threshold based on coverage, contract compliance, performance, or security. Differs from raw test pass/fail because it considers trends — coverage drop is a fail even if all tests pass.

Q37. How do you run API tests against multiple environments? A37. Externalize base URLs, credentials, and feature flags into environment configs. CI runs against an ephemeral env per PR; nightly runs against staging.

Q38. How do you handle test data in CI? A38. Generate from schemas (faker, JSON Schema Faker), seed via API on test setup, tear down on teardown. Avoid hand-curated fixtures — they rot and couple tests.

Q39. What is a flaky API test and how do you fix it? A39. Non-deterministic — passes sometimes, fails other times. Fixes: remove time dependencies (use clocks you can control), isolate state, mock external services, deflake retries with strict assertions.

7. Tools and platforms

Q40. Compare Postman, Total Shift Left, and ReadyAPI. A40. Postman is great for exploration; manual collection authoring at scale. ReadyAPI is enterprise but heavyweight and code-leaning. Total Shift Left is AI-native and spec-first — schema-aware test generation, contract gates, six native CI plugins. See /compare/totalshiftleft-vs-postman and /compare/totalshiftleft-vs-readyapi.

Q41. When would you use a code-first tool like Karate or RestAssured? A41. When the team is Java-heavy, the API is internal, and engineering wants tests in source control next to the code. The tradeoff is authoring overhead vs. spec-driven generation. See /compare/totalshiftleft-vs-karate.

Q42. What is a mock server and when do you use one? A42. A server that responds to API calls based on the spec or examples — used to unblock consumers before producers ship, to isolate components in CI, and to simulate failure modes.

Q43. What does AI test generation do that humans don't? A43. Reads the spec exhaustively, produces 80%+ functional coverage in minutes (vs days), and generates negative cases humans skip. Humans still own design intent and ambiguous cases.

Q44. What categories of testing fit which tools? A44. See the matrix in the diagram above.

8. Behavioral and scenario questions

Q45. Describe a time you found a critical bug through API testing. A45. (Behavioral.) Frame: situation, action, result. Quantify impact ("blocked a $700K-revenue release") if you can.

Q46. A new API has no spec. How do you start testing it? A46. Capture traffic, infer the contract into an OpenAPI doc, agree it with the producer, lint it, then drive automation off it. Don't write tests against undocumented behavior.

Q47. The team owns 200 microservices. How do you scale API testing? A47. Centralize on spec-driven automation. Make the OpenAPI repo the source of truth. AI-generate baseline coverage. Wire contract tests into a shared CI library. Rank services by traffic and risk for hand-written depth.

Q48. Tests pass in CI but fail in staging. Why? A48. Environment drift — different config, different downstream versions, different data. Compare deployed image SHAs, run the same tests against both with identical inputs, log diffs.

Q49. The product owner wants UI tests instead of API tests. How do you respond? A49. Show the cost-and-coverage curve: an API test costs ~10 ms and is stable; the equivalent UI test costs ~10 s and flakes. For the same budget, API tests find more bugs faster. UI tests still matter — but for UI behavior, not for backend logic.

Q50. How do you handle a breaking change to a public API? A50. Versioning (URL or header), deprecation timeline, dual-running old and new for one major release, contract tests in both shapes, consumer notification.

API testing interview prep checklist

• ✔ Re-read the OpenAPI 3.1 spec at least once
• ✔ Build a working contract test with Schemathesis or Total Shift Left
• ✔ Memorize the OWASP API Security Top 10
• ✔ Know the difference between idempotent and safe HTTP methods
• ✔ Know status code categories cold
• ✔ Run an API test in CI (GitHub Actions, GitLab, or Jenkins)
• ✔ Practice explaining shift-left to a non-technical interviewer
• ✔ Have one war-story bug ready that you found through API testing

FAQ

What are the most common API testing interview questions in 2026? The most common questions cluster into six themes: API testing fundamentals, HTTP and REST mechanics, contract and schema validation, security (OWASP API Top 10), performance, and CI/CD integration. Senior interviews add shift-left strategy and AI-assisted test generation.

How do I prepare for an API testing interview? Practice with a real OpenAPI spec — import one into Postman or Total Shift Left, write contract tests, and run them in CI. Review the OWASP API Top 10. Memorize the difference between idempotent and safe methods, status code categories, and authentication flows.

What is the difference between API testing and integration testing? API testing validates the contract a single service exposes. Integration testing validates how multiple services compose. There is overlap, but API testing is narrower and runs much faster.

How do you test an API without documentation? Capture traffic with a proxy (Charles, mitmproxy), reverse-engineer the contract, build an OpenAPI spec from the captured requests, then use it as the source of truth for tests. AI tools can assist with spec inference.

What is the OWASP API Security Top 10? A list of the most critical API security risks — broken object-level authorization, broken authentication, excessive data exposure, unrestricted resource consumption, broken function-level authorization, unrestricted access to sensitive flows, SSRF, security misconfiguration, improper inventory management, and unsafe consumption of APIs.

How does AI change API testing interviews? Senior interviews now ask candidates to evaluate AI-generated tests for coverage gaps, false positives, and contract drift — not just hand-write tests. Familiarity with schema-aware AI generators is a differentiator.

Conclusion

A 2026 API testing interview is a strategy conversation as much as a syntax quiz. Master HTTP and REST mechanics, but invest equally in contract testing, OWASP API security, and shift-left CI patterns. If you can talk fluently about both sides of the traditional-vs-API-first diagram and bring one concrete bug story, you will outperform candidates who only memorized verbs and status codes.

Ready to practice on a real platform? Start a free Total Shift Left account — import an OpenAPI spec and run your first contract test in under five minutes.