API testing interview questions (2026)

API testing has quietly become one of the most-expected skills for QA and SDET roles — and one of the better-paid ones (the REST Assured / Postman skill band sits around ₹7–14 LPA, Testleaf 2025). If you can test the layer beneath the UI, you're more valuable, because that's where a lot of the real logic and the real bugs live.

This covers the questions that actually come up, by experience level, with answers written the way an interviewer wants to hear them. Like the Selenium interview questions guide, the goal is understanding, not memorising — the scenario questions at the end separate people who've done it from people who've read about it.

API testing fundamentals

What is API testing and why does it matter?

API testing validates the application's business logic, data handling, and responses directly at the API layer, without going through the UI. It matters because it's faster and more stable than UI testing, catches logic bugs earlier (shift-left), and tests the contract between systems. A strong answer notes that API tests sit lower in the test pyramid — you want many of them relative to slower UI tests.

What's the difference between REST and SOAP?

REST is an architectural style (stateless, standard HTTP methods, typically JSON, lightweight); SOAP is a stricter protocol (XML-based, formal contracts via WSDL, built-in standards for security/transactions). REST dominates modern web APIs; SOAP still appears in some enterprise/legacy systems. The signal: know why REST won for most web use without dismissing where SOAP still fits.

What are the main HTTP methods and when are they used?

GET (retrieve), POST (create), PUT (replace/update), PATCH (partial update), DELETE (remove). The maturity follow-up: GET, PUT, and DELETE are idempotent (repeating them has the same effect), POST is not — which matters when you design retry logic and tests.

What do you validate in an API response?

Status code, response body (data correctness and schema/structure), response headers, and response time. Beyond the happy path: error responses, boundary and invalid inputs, authentication/authorization, and data consistency. Verifying the right status code for each scenario — e.g. that an unauthenticated request returns 401, not 200 with an error body — is a key signal.

Postman questions

How do you manage different environments in Postman?

Use environments with variables (e.g. base_url, tokens) so the same collection runs against dev/staging/prod by switching environment. Combine with collection-level and global variables; keep secrets out of shared collections.

What are pre-request and test scripts in Postman?

Pre-request scripts run before the request (e.g. generating a token, setting variables); test scripts run after (assertions on status, body, headers, via pm.test and pm.expect). Chaining requests by extracting a value from one response into a variable for the next is a common, expected pattern.

How do you automate and run Postman collections in CI?

Newman, Postman's command-line runner, executes collections (with environment files) and integrates into CI pipelines, producing reports. Mentioning CI integration signals you think beyond manual clicking.

REST Assured questions

How is a REST Assured test structured?

The given/when/then BDD-style syntax: given() sets up the request spec (headers, params, body, auth), when() fires the request (method + endpoint), then() validates the response (status, body via matchers, headers). It's a Java library, so it integrates naturally with TestNG/JUnit and Maven/Gradle projects.

How do you validate a JSON response in REST Assured?

Hamcrest matchers in the then() block (e.g. body("user.id", equalTo(123))), JSON schema validation for structure, and extracting values with .extract() for further assertions or chaining. Schema validation is the answer that signals contract-testing awareness.

How do you handle authentication in REST Assured?

Depends on the scheme — basic auth, bearer tokens (set the Authorization header), OAuth2, or API keys. Typically you obtain a token (often in a setup step) and pass it on subsequent requests. Keeping credentials in config, not code, is the hygiene point.

By experience — what's emphasised

• Freshers: concepts — what an API is, REST vs SOAP, HTTP methods and status codes, what to validate.
• Experienced: automation — REST Assured/Postman frameworks, auth flows, data-driven API tests, CI integration.
• Senior: design and judgment — contract testing, mocking/stubbing strategy, API performance and security basics, how API tests fit the overall test strategy.

Scenario questions

How would you test a paginated endpoint?

Validate the first page, a middle page, and the last page; check page size, total count, boundary behaviour (page beyond the last, page size of 0 or a huge value), and consistency of ordering. Confirm the pagination metadata matches the actual data.

How would you test an authentication-protected flow?

Verify access with a valid token (expected data), without a token (401), with an expired/invalid token (401), and with a valid token but insufficient permissions (403). Check that protected data isn't leaked in any error path.

A third-party API your tests depend on is flaky. What do you do?

Isolate your tests from its instability — mock or stub the third-party in your own test environment so you're testing your integration logic deterministically, and test against the real one separately and less frequently. This shows you understand test reliability and the difference between testing your code and testing someone else's service. Where these skills fit is in the SDET roadmap.

Where CareerIntel fits (honestly)

Knowing the answers gets you through the technical round — but walking in knowing the company's APIs and what they actually test turns the interview into a conversation. That company-level preparation is part of what CareerIntel delivers.