API Testing Interview Questions & Answers (2026)
These interviews assess your ability to design, execute, and validate API tests, understand HTTP fundamentals, and use automation frameworks. Success comes from mastering request/response validation, handling authentication, performance checks, and integrating tests into CI pipelines. Demonstrate clear reasoning, trade‑off awareness, and practical tool knowledge to stand out.
22 questions · updated Aug 29, 2026
Quick facts
| Typical rounds | Phone screen, technical coding, system design, and final onsite |
| Key skills evaluated | REST principles, JSON schema validation, test automation, performance testing |
| Common tools | Postman, RestAssured, JMeter, Karate, Newman |
| Preferred experience | 2‑5 years of API testing in Agile environments |
| Success metric | Ability to write maintainable, data‑driven tests and explain failure diagnostics |
Questions
Beginner
What are the main components of an HTTP request and response you would validate in API testing?
An HTTP request consists of the method, URL, headers, query parameters, and optional body. Validation should cover the method correctness, endpoint path, required headers (like Content‑Type or Authorization), and payload format. The response includes status code, headers, and body. A strong candidate checks that the status code matches expectations, headers contain necessary values (e.g., CORS, caching), and the body conforms to a schema or contains expected data, explaining why each element matters for reliability.
How do you test authentication mechanisms such as OAuth 2.0 in API tests?
First obtain a valid token using the OAuth token endpoint with client credentials or password grant, then include the token in the Authorization header for subsequent calls. Validate token expiry handling by simulating expired tokens and confirming the API returns 401 or 403. Explain trade‑offs: hard‑coding tokens speeds up tests but reduces realism; using a token refresh flow adds coverage for token lifecycle and demonstrates deeper understanding of security flows.
What is a JSON schema and how would you use it in API testing?
A JSON schema defines the structure, data types, and constraints of a JSON payload. In tests, you load the schema and validate the response body against it, ensuring required fields exist, types match, and value ranges are respected. This catches contract violations early. A strong answer mentions tools like AJV or RestAssured's schema validation and notes that schemas enable contract‑first development and reduce brittle field‑by‑field assertions.
Explain the difference between functional and non‑functional API testing.
Functional testing verifies that an API returns correct data, handles edge cases, and respects business rules—essentially ‘does it work?’. Non‑functional testing measures qualities like performance, reliability, security, and scalability—‘how well does it work?’. Interviewers expect you to discuss load testing response times, security scans for injection, and rate‑limit checks, showing you can assess both correctness and operational characteristics.
How would you handle flaky API tests caused by external service latency?
Introduce retries with exponential backoff, isolate flaky calls using mocks or service virtualization, and add timeout thresholds that reflect realistic SLAs. Explain that retries mitigate transient network issues but can mask genuine performance problems, so you should also log latency metrics and fail tests if latency exceeds acceptable limits. This demonstrates awareness of both test stability and production expectations.
Intermediate
Describe how you would use data‑driven testing for API endpoints.
Create a data source (CSV, JSON, or database) containing varied input combinations and expected outcomes. Loop through each row, constructing requests dynamically and asserting responses against the data. This reduces code duplication and expands coverage. Emphasize that separating data from test logic enables easy addition of edge cases and supports CI pipelines where test data can be versioned alongside code.
What is contract testing and how does it differ from traditional API testing?
Contract testing focuses on the agreement between a consumer and provider, verifying that the provider adheres to the consumer‑defined contract (e.g., using Pact). Traditional testing validates the provider’s implementation against its own specifications. Contract tests catch breaking changes early, especially in microservice architectures, by running consumer‑driven expectations against the provider stub or live service. Highlight that this reduces integration failures and supports independent deployment pipelines.
How do you perform performance testing for an API and what metrics matter most?
Use tools like JMeter or Gatling to simulate concurrent users and measure response time, throughput (requests per second), error rate, and latency percentiles (p95, p99). Establish baseline SLAs, then compare against load spikes. Explain that response time indicates user experience, throughput shows capacity, and error rate reveals stability under load. Also discuss thinking about warm‑up periods and realistic payload sizes to mimic production traffic.
Explain how you would test pagination in a REST API.
Validate that the API returns the correct number of items per page, includes navigation links or tokens, and respects boundary conditions (first, last, out‑of‑range pages). Use a loop to request successive pages, ensuring no duplicates and that the total count matches expectations. Discuss trade‑offs: testing only first/last pages is faster, but full iteration uncovers off‑by‑one errors and inconsistent total counts, showing thoroughness.
What strategies would you use to mock external dependencies in API tests?
Leverage tools like WireMock or MockServer to stub external HTTP calls, defining expected request patterns and responses. Alternatively, use service virtualization platforms for more complex protocols. Mocking isolates the API under test, speeds up execution, and enables deterministic results. Mention that over‑mocking can hide integration issues, so you should complement mocks with a few end‑to‑end tests against real services.
How do you validate error handling and response codes for invalid inputs?
Create negative test cases that send malformed JSON, missing required fields, or invalid query parameters. Assert that the API returns appropriate status codes (400, 422) and descriptive error messages. Explain that checking error payload structure ensures clients can programmatically handle failures, and that testing edge cases demonstrates robustness and defensive programming.
Describe how you would integrate API tests into a CI/CD pipeline.
Store tests in version control, run them in a build stage using a headless runner (e.g., Newman for Postman collections or Maven for RestAssured). Fail the build on test failures, publish reports, and optionally gate deployments behind a quality gate. Highlight that parallel execution reduces feedback time, and that environment variables allow tests to run against dev, staging, and prod endpoints without code changes.
Advanced
What is the purpose of idempotency in API design and how do you test it?
Idempotency ensures that repeating the same request (especially POST) yields the same result without side effects, which is crucial for retries. Test by sending the same request multiple times with an Idempotency-Key header and verifying that only one resource is created or state change occurs. Confirm that subsequent responses return the same status code and resource identifier, demonstrating reliability under network failures.
How would you test rate limiting and what response would you expect?
Issue a burst of requests exceeding the documented limit and observe the API’s behavior. Expect HTTP 429 Too Many Requests with a Retry-After header indicating when to retry. Verify that the limit resets after the interval and that legitimate traffic resumes. Explain that testing both hard limits and graceful degradation shows understanding of service protection mechanisms.
Explain how you would test a GraphQL API versus a REST API.
For GraphQL, construct queries and mutations as payloads, then validate the response shape against the expected schema, checking field selection, nesting, and error handling. Unlike REST, you test a single endpoint with varied queries, so focus on query validation, variable injection, and resolver performance. Mention using tools like Apollo’s testing utilities or Postman’s GraphQL support to illustrate adaptability.
What is chaos testing for APIs and when would you apply it?
Chaos testing introduces controlled failures (latency spikes, network partitions, service crashes) to verify system resilience. Apply it after functional stability is achieved, using tools like Gremlin or Chaos Mesh to inject faults into API dependencies. Observe how the API degrades—does it return fallback responses, proper error codes, or maintain SLA? This demonstrates a proactive approach to reliability and fault tolerance.
How do you approach testing versioned APIs and ensuring backward compatibility?
Maintain separate test suites for each version, validating that older clients still receive expected responses from newer service versions. Use contract tests to compare schemas across versions, and run regression tests that simulate legacy payloads. Explain that deprecation warnings, header versioning, and thorough regression coverage help guarantee that upgrades do not break existing integrations.
Describe how you would test an API that uses streaming responses (e.g., Server‑Sent Events).
Open a persistent connection to the endpoint, then consume the stream, validating each event’s format, order, and payload. Use a timeout to ensure the stream stays alive for the expected duration and that no unexpected disconnects occur. Highlight handling of back‑pressure and verifying that the server respects the client’s consumption rate, showing depth in testing real‑time APIs.
What techniques would you use to test API security beyond authentication?
Perform penetration testing for injection attacks (SQL, XML), test for insecure direct object references by manipulating IDs, verify proper use of HTTPS, and check for sensitive data exposure in error messages. Use OWASP ZAP or Burp Suite to automate scans, and assert that security headers (CSP, HSTS) are present. Explain that comprehensive security testing protects data integrity and compliance.
How do you validate that an API complies with OpenAPI/Swagger specifications?
Generate a client stub from the OpenAPI spec and compare it against the live API using tools like swagger‑validator or Dredd. Run tests that ensure every defined path, method, and response schema exists and matches the spec. Highlight that mismatches indicate contract drift, and that automated spec validation in CI catches regressions early, reinforcing contract fidelity.
Explain the role of middleware in API testing and how you would verify its behavior.
Middleware handles cross‑cutting concerns such as logging, authentication, and request transformation. To test it, send requests that trigger specific middleware paths and assert side effects: e.g., check that logs contain expected entries, that headers are added or stripped, and that request bodies are transformed correctly. Use spies or mock frameworks to intercept middleware calls, demonstrating awareness of the full request lifecycle.
How would you test an API that supports both JSON and XML payloads?
Create parallel test cases for each content type, setting the Accept and Content-Type headers accordingly. Validate that the response matches the requested format and that schema validation works for both JSON (using JSON Schema) and XML (using XSD). Discuss handling of differences in field naming conventions and ensuring that business logic remains consistent across formats, showing thorough cross‑format coverage.
Common mistakes
- Hard‑coding authentication tokens instead of generating them dynamically
- Skipping negative test cases and only validating happy paths
- Ignoring response header validation, leading to missed contract violations
- Over‑relying on UI‑level tools without asserting at the protocol level
- Failing to integrate tests into CI, causing stale test suites
Study plan
- Review HTTP fundamentals and status code semantics
- Practice schema validation with JSON Schema and XML XSD
- Build a small API test suite using RestAssured or Postman and add data‑driven cases
- Add performance and security tests with JMeter and OWASP ZAP
- Integrate the suite into a CI pipeline and iterate based on flaky test analysis
FAQ
Do I need to know how to code to pass API testing interviews?
Yes, you should be comfortable writing test scripts in a language like Java, JavaScript, or Python, because interviewers expect you to demonstrate automation, data‑driven testing, and integration with CI tools.
What is the most important metric when measuring API performance?
Response time percentiles (especially p95 and p99) are critical because they reflect real‑user experience under load, while throughput and error rate provide context for capacity and stability.
How many API test cases should I include in my portfolio?
Showcase a balanced set: at least five functional tests, three negative tests, two performance tests, and one security test. Quality and depth matter more than sheer quantity.
Can I use Postman collections for a coding interview?
Postman collections are acceptable for demonstrating test design, but be ready to translate them into code (e.g., using Newman or a language SDK) to show programmatic proficiency.
What should I do if I don’t have access to the API spec before the interview?
Ask clarifying questions, infer likely contracts based on REST conventions, and demonstrate how you would discover and validate the spec using tools like Swagger UI or by inspecting sample responses.
Related
Ready for your next interview?
Download MiPrep AI. Load your resume and the job description. Show up ready.
Free tier · No credit card · macOS 14+ · Windows 10+
Free tier · No credit card · Runs on your Mac or Windows machine