DEV Community

alexrai
alexrai

Posted on

API Testing Interview Questions: The Complete 2026 Reference Guide for Developers

#api #testing #beginners #ai

Sitting across from an interviewer who asks "Walk me through how you'd test this endpoint" is a different kind of pressure than any coding challenge. API testing questions test your mental model of systems — not just syntax.

This guide is structured as a reference you can return to at any stage of prep. Each section builds on the last, from core definitions to architecture-level thinking.

Before You Start: What Interviewers Are Really Measuring

Most candidates prepare answers. Strong candidates prepare understanding.

When a company asks API testing questions, they are evaluating:

  • Can you reason about system boundaries?
  • Do you think about failure, not just success?
  • Have you actually tested APIs — or just read about it?

Keep that in mind as you go through every section below.

PART 1 — Core Concepts Every Candidate Must Own

Q1. Define API testing in your own words.

API testing validates the communication layer between software systems — checking that requests produce the right responses, that data is accurate, that failures are handled correctly, and that the system performs reliably under real-world conditions. Crucially, it does all of this without touching the user interface.

Before your interview, make sure you have a solid mental picture of what is API testing in software — because follow-up questions will probe exactly how deep that understanding goes.

Q2. Why does API testing matter more in microservices than in monolithic applications?

In a monolith, components share the same process — failures stay contained and easy to trace. In microservices, every service communicates over a network via APIs. One broken API cascades into failures across every dependent service.

This is why API testing in microservices isn't optional — it's the primary mechanism for validating that independently deployed services still work together.

Q3. Where does API testing sit in the testing pyramid? 

        /\
       /  \   ← E2E / UI Tests (slow, brittle, expensive)
      /----\
     /      \  ← API / Integration Tests (fast, stable, high ROI)
    /--------\
   /          \ ← Unit Tests (fastest, most isolated)
  /____________\
Enter fullscreen mode Exit fullscreen mode

API tests occupy the middle layer. They're faster and more reliable than UI tests, and they cover integration logic that unit tests can't reach. This combination — speed + coverage — is what makes API testing the highest-ROI layer for most teams.

Q4. What are all the types of API testing you should know?

Type What It Validates
Functional Correct behavior for valid and invalid inputs
Contract Agreement between consumer and provider is honored
Security Auth, authorization, injection protection, rate limits
Performance / Load Response times and stability under traffic
Integration Multiple services communicating correctly end-to-end
Regression Recent changes haven't broken existing behavior
Fuzz Testing Unexpected/random inputs don't cause crashes

Name all seven. Most candidates stop at three.

Q5. What is the full list of HTTP methods and when is each used?

Method Action Idempotent? Success Code
GET Read a resource ✅ Yes 200
POST Create a resource ❌ No 201
PUT Replace a resource ✅ Yes 200
PATCH Partially update ✅ Yes 200
DELETE Remove a resource ✅ Yes 200 / 204
HEAD Like GET, headers only ✅ Yes 200
OPTIONS Describe allowed methods ✅ Yes 200

The idempotency column is what separates good answers from great ones.

Q6. What HTTP status codes must you know cold?

2xx — Success

  • 200 OK
  • 201 Created
  • 204 No Content

4xx — Client errors

  • 400 Bad Request
  • 401 Unauthorized (not authenticated)
  • 403 Forbidden (authenticated, not permitted)
  • 404 Not Found
  • 409 Conflict (duplicate resource)
  • 422 Unprocessable Entity (validation failed)
  • 429 Too Many Requests

5xx — Server errors

  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable

Interview trap: many candidates confuse 401 and 403. 401 means "I don't know who you are." 403 means "I know who you are, but you can't do this."

PART 2 — Intermediate Questions

Q7. What is the difference between PUT and PATCH?

PUT replaces the entire resource. Send only {"email": "new@test.com"} via PUT and every other field gets wiped.

PATCH updates only the fields you send. The rest stay unchanged.

Testing implication: PUT tests must include the full resource payload. PATCH tests can be targeted at individual fields — and should include tests for partial updates where unspecified fields remain intact.

Q8. What is API contract testing and why does it exist?

A contract is a formal agreement between a consumer (the service that calls an API) and a provider (the service that serves it). Contract testing verifies that this agreement holds — independently, without needing both services running.

Why it exists: In microservices, Team A's service can break silently when Team B changes their API. Contract testing catches this at commit time, before anything reaches a shared environment.

Standard tool: Pact. The consumer defines expectations; the provider verifies it can fulfill them.

Q9. How do you test an API that sits behind authentication?

Step-by-step:

  1. Obtain credentials — login endpoint, OAuth flow, or static API key

  2. Attach to requests — typically Authorization: Bearer <token>

  3. Test the happy path — valid token, correct response

  4. Test failure cases:

  • No token → 401
  • Expired token → 401
  • Valid token, wrong permission → 403
  • Tampered token → 401

Step 4 is where most candidates stop short. Never test auth without negative cases.

Q10. What is idempotency and why does it matter in API testing?

An idempotent operation produces the same result no matter how many times it is called. GET, PUT, DELETE, and PATCH should be idempotent. POST typically is not.

Why it matters in testing: if DELETE is idempotent, calling it twice on the same resource should return 404 on the second call — which is correct behavior. Your test must handle this. If your DELETE accidentally creates a new resource on the second call, idempotency is broken and that is a serious bug.

Q11. How do you approach negative testing for an API?

For every endpoint, think through:

  • Missing required fields → expect 400 or 422
  • Wrong data types → expect 400
  • Out-of-range values → expect 400 or 422
  • Non-existent resource IDs → expect 404
  • Duplicate creation → expect 409
  • Exceeding rate limits → expect 429
  • Malformed JSON → expect 400

Most bugs live in negative paths. Teams that only write positive tests discover those bugs in production.

Q12. What is the difference between mocking and stubbing?

Stub Mock
What it does Returns a fixed response Returns a response AND verifies calls were made
Use when You just need a dependency to respond You need to assert a specific interaction happened
Strictness Low High

Mocks are more powerful but tie tests more tightly to implementation. Stubs are simpler and better for isolating components.

Q13. How do you validate a response beyond just the status code?

Three layers every API test should cover:

  1. Status code — Is it the expected HTTP code?
  2. Schema — Are the correct fields present, with the correct types?
  3. Values — Are the actual data values correct for this specific request?

Validating only the status code is one of the most common gaps in API test suites. A 200 OK with completely wrong data is still a failing test — your assertions just didn't catch it.

Q14. What is the difference between REST, SOAP, and GraphQL from a testing standpoint?

REST SOAP GraphQL
Format JSON / XML XML only JSON
Endpoints Multiple Single (WSDL) Single /graphql
Testing focus HTTP methods, status codes, response schema XML envelope, WSDL contract, fault elements Query structure, field-level responses, mutation side effects
Primary tools Postman, Keploy, RestAssured SoapUI GraphQL-specific clients

PART 3 — Advanced Questions (Senior Roles)

Q15. How do you design an API test strategy from scratch for a new service?

Walk through this framework:

  1. Understand the contract — Start from the OpenAPI spec or existing documentation
  2. Map test types needed — Functional, contract, security, performance
  3. Prioritize by risk — Auth endpoints, payment flows, and data-sensitive operations first
  4. Define test data strategy — How is test data created, isolated, and cleaned up?
  5. Integrate into CI/CD — Tests run on every PR, not just on merge
  6. Set baselines — Performance benchmarks, coverage thresholds

Q16. How do you test APIs in a CI/CD pipeline?

Key principles:

  • Tests must be deterministic — same result on every run
  • Tests must be isolated — no shared mutable state between test runs
  • Tests should run on every pull request, not just after merge
  • Failures should block the merge — not just send a Slack notification
  • Contract tests run before integration tests — they're cheaper and catch breaking changes earlier

Q17. How do you approach performance testing for an API?

  1. Define what "acceptable" means — p95 response time, error rate under load
  2. Establish baseline metrics before any load is applied
  3. Simulate realistic traffic patterns — not synthetic uniform load
  4. Ramp load gradually to identify the threshold where behavior degrades
  5. Distinguish where the bottleneck lives — API layer, database, or downstream dependency (distributed tracing helps here)

Tools: k6, Gatling, JMeter.

Q18. What is the OWASP API Security Top 10 and which items should you test for?

The OWASP API Security Top 10 defines the most critical API security risks:

  1. Broken Object Level Authorization (BOLA) — Can user A access user B's data?
  2. Broken Authentication
  3. Broken Object Property Level Authorization — Excessive data exposure
  4. Unrestricted Resource Consumption — No rate limiting
  5. Broken Function Level Authorization — Can a regular user call admin endpoints?
  6. Unrestricted Access to Sensitive Business Flows
  7. Server Side Request Forgery (SSRF)
  8. Security Misconfiguration
  9. Improper Inventory Management
  10. Unsafe Consumption of APIs

Knowing this list by name at a senior interview is table stakes.

Q19. How do you handle flaky API tests?

Root causes of flaky API tests:

  • Shared mutable state between test runs
  • Fixed sleep/wait times instead of proper polling conditions
  • Dependency on external services that aren't reliably available
  • Tests that depend on execution order

Fix by: isolating state per test, using mocks for external dependencies, implementing retry logic with exponential backoff where appropriate, and quarantining (never ignoring) flaky tests until root cause is resolved.

Q20. How does AI-assisted API test generation work and where is it headed?

Tools like Keploy record real API traffic and automatically generate test cases from observed behavior — instead of requiring engineers to write tests by hand against a spec. This means tests reflect actual usage patterns, not assumed ones.

The direction: as APIs evolve, test suites that are generated from traffic evolve with them automatically. The shift is from "write tests to match the spec" to "observe real behavior and continuously validate against it." This matters especially for regression testing, where the cost of manually updating tests after every API change is prohibitive at scale.

PART 4 — Quick-Fire Questions (Rapid Round Style)

These are the short questions that get asked mid-interview to test breadth:

Q: What tool would you use for contract testing? → Pact

Q: What does a 422 mean vs a 400? → 400 is malformed input; 422 is well-formed input that fails business validation

Q: What's the N+1 problem in GraphQL testing? → One query triggering N additional database queries per nested field — a performance issue specific to GraphQL resolvers

Q: What's the difference between latency and throughput? → Latency is how long one request takes; throughput is how many requests the system handles per second

Q: What does idempotent mean in plain English? → Doing the same thing multiple times produces the same result as doing it once

Q: What is a test fixture? → The fixed state or setup required before a test can run

Q: What is a smoke test for an API? → A minimal set of tests that verify the API is up and basic operations work — run before deeper test suites

Q: What's the risk of testing only happy paths? → You'll miss bugs that only appear with invalid inputs, edge cases, or unexpected system states — which is where most production bugs live

Final Preparation Checklist

Before your interview, make sure you can:

  • [ ] Explain the testing pyramid and where API testing sits
  • [ ] Name all 7 types of API testing with examples
  • [ ] Define idempotency and name which HTTP methods should be idempotent
  • [ ] Walk through a complete test case for a POST endpoint
  • [ ] Explain contract testing without needing to look it up
  • [ ] Name at least 5 items from the OWASP API Security Top 10
  • [ ] Describe how you'd design an API test strategy from scratch
  • [ ] Explain the difference between 401 and 403

Need a foundational refresher before diving into interview prep? What is API testing in software covers the complete picture from first principles.

Top comments (0)