API Testing Interview Questions and Answers (80+ Q&As)

Why API testing interviews have changed

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.

API testing interview questions by topic

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. A strong answer adds that this needs two identities and a written rule of who may see what. Tools that automate it, such as Shift-Left API's API security testing add-on, ask for exactly that: a second test user and an access matrix marking each endpoint Deny, Own data only or Allow.

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. A good follow-up point is whether the load test reuses the functional suite or duplicates it: Shift-Left API's load testing add-on (paid; included in the Trial) builds smoke, load, stress, spike, soak and other runs from existing functional tests, and compares baselines with a statistical test over p95 so normal variation isn't reported as a regression.

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. Strong candidates also separate why a test failed before touching it: a test defect, a data issue, an environment problem, or a real product bug. Tools are starting to do this triage — Shift-Left API, for example, groups a failed run into causes with a verdict for each, telling a gateway error page or rate limiting apart from a genuine permission refusal.

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. Shift-Left API (from Total Shift Left) is AI-native and spec-first — schema-aware test generation from specs and requirement documents, contract gates, first-party GitHub Actions, Jenkins and Azure DevOps integrations plus a REST API for any other pipeline, and Postman collection import for teams moving off collections. See the Shift-Left API platform, the Postman alternative page and the ReadyAPI alternative page.

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 REST Assured 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 — a good candidate can explain how a schema-aware generator builds tests from an OpenAPI spec. Humans still own design intent and ambiguous cases. A sharp follow-up is what happens when a generated test fails: in Shift-Left API, AI fixes are proposals a person accepts, each citing the spec, requirement and run evidence, a negative test is never weakened into one that can't fail, and a product bug is never "fixed" by editing the test.

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 questions by experience level

Interviewers calibrate to your years of experience. The same topic (say, authentication) is a definition question for a fresher and a design question for a lead. Practise at your level and one level above.

API testing interview questions for freshers

Q51. What is an API, and what is an endpoint? A51. An API is a defined way for one program to ask another for data or actions. An endpoint is one address in that API, such as GET /users/42, combining a URL path and an HTTP method.

Q52. What is the difference between API testing and UI testing? A52. API testing calls the service directly and checks responses; UI testing drives the screens a user sees. API tests are faster and more stable and find logic errors earlier; UI tests are still needed for layout and user flows. See API testing vs UI testing.

Q53. What is the difference between a path parameter and a query parameter? A53. A path parameter identifies the resource (/orders/42); a query parameter filters or modifies the request (/orders?status=paid&limit=20). Both need tests for missing, malformed and boundary values.

Q54. What is JSON, and what is a JSON Schema? A54. JSON is the text format most APIs use for request and response bodies. A JSON Schema describes what valid JSON looks like (required fields, types, formats), so a test can validate a whole response at once.

Q55. Is API testing manual or automated? A55. Both. You explore an API manually with Postman or curl to learn how it behaves, then automate the repeatable checks so they run on every build. See API test automation: what it is and how to start.

API testing interview questions for 3 years of experience

Q56. How do you chain requests, for example create then read? A56. Extract a value from the earlier response (an ID or token) into a variable and use it in the next request. In Postman that is pm.collectionVariables.set in a test script; in code it is a return value or fixture. Always clean up what you created.

Q57. How do you run the same test with many data sets? A57. Data-driven testing: one test, many rows from CSV, JSON or a database, each row with its own expected result. Include invalid rows on purpose so negative cases are covered.

Q58. How do you handle an OAuth 2.0 token in an automated suite? A58. Fetch the token once per run (client credentials for service tests), cache it, refresh it before it expires, and keep the client secret in the CI secret store. Never hard-code tokens in tests.

Q59. What do you assert besides the status code? A59. The full response schema, key field values, headers such as Content-Type and caching, response time, and side effects (the record really exists afterwards).

Q60. How do you test an endpoint that depends on a third-party service? A60. Stub or mock the third party in functional tests so failures are yours, and run a smaller set of tests against the real dependency in a separate stage.

API testing interview questions for 5 years of experience

Q61. How would you design an API automation framework from scratch? A61. Layers: configuration (environments, secrets), a client with auth and logging, request builders or endpoint objects, reusable assertions including schema validation, test data factories, the tests themselves, reporting, and a CI entry point. Keep tests independent so they can run in parallel.

Q62. How do you keep a large API suite fast enough for every pull request? A62. Tag by risk and speed, shard across runners, run a smoke subset on feature branches and the full suite on main, and replace slow end-to-end setups with API-level data creation.

Q63. How do you decide what to automate first? A63. Rank endpoints by business risk and change frequency. Automate authentication, money-moving and data-changing operations first, then high-traffic reads, then the long tail.

Q64. How do you test idempotency of a payment endpoint? A64. Send the same request twice with the same Idempotency-Key. Assert one charge is created, the second response matches the first, and a different key creates a second charge.

Q65. How do you validate that a response matches the OpenAPI spec? A65. Load the spec, find the response schema for the operation and status code, and validate the body against it in every test, or let a spec-driven tool do it for every operation. Fail the test on extra fields if the spec forbids them.

API testing interview questions for 10 years of experience

Q66. How would you set an API testing strategy for 200 microservices? A66. Make each team own its service's contract (OpenAPI) and tests; enforce a shared minimum in CI (spec lint, schema validation, contract tests between consumers and producers); centralise tooling and reporting; and spend hand-written depth on the highest-risk services.

Q67. How do you choose between code-first frameworks and a spec-driven platform? A67. Look at who writes tests, spec maturity, protocols, CI and governance needs, and total cost. Code-first fits developer-owned suites; spec-driven fits broad coverage and mixed-skill teams. Many organisations use both. See the best API testing tools.

Q68. What quality gates would you put on a release? A68. Contract and schema checks must pass; no new critical security findings; coverage of changed endpoints must not drop; the p95 latency budget must hold; flaky tests are quarantined, not ignored.

Q69. How do you report API quality to leadership? A69. Trends, not counts: escaped defects by severity, coverage of the API surface, time from a new endpoint to its first test in CI, pipeline duration, and change-failure rate.

Q70. How do you introduce contract testing across teams that resist it? A70. Start with one producer and its two most important consumers, show a breaking change caught in a pull request, make the check advisory for a sprint, then blocking. Tooling matters less than agreeing who owns the contract.

API automation, REST Assured and Postman interview questions

API automation testing interview questions

Q71. Can API testing be automated, and what should stay manual? A71. Almost all regression checks can be automated. Exploratory testing of a new API, judging whether an error message is helpful, and one-off investigations stay manual.

Q72. What is the difference between API testing and API automation testing? A72. API testing is the activity; API automation testing is running those checks with tools or code, without a person sending each request, usually in CI.

Q73. How do you make automated API tests independent of each other? A73. Each test creates its own data, uses unique identifiers and cleans up; no test relies on the order of others or on state left by a previous run.

Q74. What makes an automated API test flaky, and how do you prove a fix? A74. Shared data, timing assumptions, unstable dependencies and environment drift. Prove the fix by running the test many times in a loop and in parallel before taking it out of quarantine.

REST Assured interview questions

Q75. What does a basic REST Assured test look like? A75. A given/when/then chain:

given()
    .baseUri("https://api.example.com")
    .header("Authorization", "Bearer " + token)
    .contentType(ContentType.JSON)
    .body(Map.of("sku", "A-1", "qty", 2))
.when()
    .post("/v1/orders")
.then()
    .statusCode(201)
    .body("status", equalTo("pending"))
    .body(matchesJsonSchemaInClasspath("schemas/order.json"));

Q76. What are RequestSpecification and ResponseSpecification for? A76. Reusable building blocks: a RequestSpecification holds the base URI, auth and headers shared by many tests; a ResponseSpecification holds common expectations such as status and content type. They remove duplication across the suite.

Q77. How do you extract a value from a response in REST Assured? A77. Use .extract().path("id"), or .extract().as(Order.class) to deserialise into a POJO, then pass the value to the next request.

Q78. How do you validate a JSON schema in REST Assured? A78. Add the json-schema-validator module and assert body(matchesJsonSchemaInClasspath("schemas/order.json")).

Q79. How do you run REST Assured tests in CI? A79. They are ordinary JUnit or TestNG tests, so mvn test or gradle test runs them and the Surefire or Gradle reports publish JUnit XML. Pass base URLs and secrets as environment variables. Full walkthrough: REST Assured tutorial.

Postman interview questions

Q80. What is the difference between environment, collection and global variables in Postman? A80. Global variables apply everywhere, collection variables to one collection, and environment variables to whichever environment is selected (dev, staging). Use environments for anything that changes between deployments.

Q81. How do you write a test in Postman? A81. In the request's test script:

pm.test("order is created", () => {
  pm.response.to.have.status(201);
  const body = pm.response.json();
  pm.expect(body.status).to.eql("pending");
  pm.collectionVariables.set("orderId", body.id);
});

Q82. What is a pre-request script in Postman used for? A82. Code that runs before the request in Postman: generating a timestamp or signature, fetching a token, or setting a variable the request needs.

Q83. How do you run a Postman collection in CI? A83. With the Postman CLI or Newman, for example newman run collection.json -e staging.json --reporters cli,junit, then publish the JUnit report.

Q84. What are the limits of Postman for test automation at scale? A84. Every request and assertion is written by hand, collections drift from the spec, and the runner reports pass or fail without showing which endpoints have no test. Strong answers mention coverage against the spec and versioning collections in Git. See API testing with Postman and why Postman collections aren't enough for CI/CD.

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

Related reading: REST API testing best practices · shift-left testing.

The live-coding round and what each round assesses

The live-coding question you should expect

"Write a test for a paginated endpoint" comes up in most senior API testing interviews. What the interviewer is checking is whether you test the pagination contract rather than the first page:

import requests

def test_pagination_contract(auth_headers):
    seen, url, pages = set(), f"{API}/v1/orders?limit=50", 0

    while url:
        r = requests.get(url, headers=auth_headers)
        assert r.status_code == 200
        body = r.json()

        # 1. the page never exceeds the requested limit
        assert len(body["items"]) <= 50
        # 2. no item is returned twice across pages (the classic offset bug)
        ids = {i["id"] for i in body["items"]}
        assert not (ids & seen), f"duplicate ids across pages: {ids & seen}"
        seen |= ids
        # 3. ordering is stable, otherwise pagination is meaningless
        assert body["items"] == sorted(body["items"], key=lambda i: i["createdAt"])

        url, pages = body.get("next"), pages + 1
        assert pages < 100, "pagination did not terminate"

    # 4. the advertised total matches what was actually returned
    assert len(seen) == requests.get(f"{API}/v1/orders?limit=1",
                                     headers=auth_headers).json()["total"]

What each interview round is actually assessing

The questions differ by company; what they are testing does not:

The two rounds candidates prepare for least are debugging and CI/CD, and they are the two that most often decide a senior offer.

API testing interviews FAQ

What are the most common API testing interview questions? 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 API testing interview questions are asked for experienced candidates? With 3 to 5 years of experience, expect questions on designing an automation framework, data-driven tests, auth handling, CI integration, flaky tests and REST Assured or Postman specifics. With 10 years, expect strategy questions: scaling testing across many services, contract testing between teams, quality gates, tool selection, and how you measure and report quality.

What is the OWASP API Security Top 10? The OWASP list of the most critical API security risks. The 2023 edition is 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, and unsafe consumption of APIs.

Sources and further reading

• RFC 9110 — HTTP Semantics — the normative definition of methods, status codes and headers.
• OpenAPI Specification — the normative spec for describing HTTP APIs.
• OWASP API Security Top 10 (2023) — the reference list of API risk categories.

A strong API testing interview is a strategy conversation as much as a syntax quiz: know HTTP and REST mechanics cold, but invest equally in contract testing, authorization testing with two identities, and how tests run in CI. Bring one concrete bug story.

Want a real project to practise on? Get the free developer licence, import an OpenAPI spec and run your first generated suite.