Top 30 API Testing Interview Questions & Answers (2026)

API Testing Interview Questions

API Testing Interview Questions & Answers 

These are the API testing questions that come up most in QA, automation and SDET interviews — with answers short enough to say out loud and complete enough to survive the follow-up. For full explanations, start with The Complete API Testing Tutorial.

API Fundamentals (Q1–6)

Q1. What is an API?

An Application Programming Interface — a contract that lets two systems talk. The client sends a request (method, URL, headers, body); the server processes it and returns a response (status code, headers, body). A mobile app, a website and a partner system can all use the same API.

Learn more: API Testing Fundamentals

Q2. What is API testing and why is it important?

Testing the service layer directly — business logic, data, error handling, security and performance — without the UI. It's faster and more stable than UI testing, finds defects earlier (often before the UI exists), and covers cases the UI can't easily reach, such as invalid inputs or direct authorization checks.

Q3. What types of APIs are there?

By style: REST (resources over HTTP, usually JSON), SOAP (XML messages with a strict contract), GraphQL (one endpoint, the client chooses the fields) and gRPC (binary, high-performance). By audience: public, partner, internal and composite APIs.

Q4. REST vs SOAP?

Learn more: REST vs SOAP

Q5. What types of API testing are there?

Functional, validation (schema and data), negative, integration and end-to-end workflows, security (authentication, authorization, injection), performance and load, contract testing, and reliability (timeouts, retries, error handling).

Q6. Why is Postman used?

To send requests and inspect responses quickly, organize them into collections, manage environments and variables, write JavaScript tests and chain requests, create mock servers — and run collections in CI/CD with Newman.

Learn more: Postman Cheat Sheet

HTTP Methods & Status Codes (Q7–13)

Q7. What are the main HTTP methods?

GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes. Also HEAD (headers only) and OPTIONS (allowed methods, CORS preflight).

Learn more: HTTP Methods & Status Codes

Q8. PUT vs PATCH?

PUT sends the whole resource and replaces it — fields left out may be cleared. PATCH sends only the fields to change and leaves the rest untouched. PUT is idempotent; PATCH isn't guaranteed to be. When testing PATCH, GET the resource afterwards to prove the other fields didn't change.

Learn more: PUT vs PATCH

Q9. What is idempotency?

Sending the same request once or many times leaves the server in the same state. GET, PUT, DELETE, HEAD and OPTIONS are idempotent; POST isn't (two POSTs create two records); PATCH isn't guaranteed to be (a "increment counter" patch changes state each time). Test it by repeating the request and checking the final state.

Q10. Can GET create a resource?

It shouldn't. GET must be safe — no side effects — because browsers, caches and crawlers may repeat it. A GET that changes data is a design defect worth reporting. Create with POST, or with PUT when the client knows the resource's URL.

Q11. What do the status code families mean?

Learn more: HTTP Status Codes Cheat Sheet

Q12. 401 vs 403?

401 Unauthorized — not authenticated: the token is missing, expired or invalid. 403 Forbidden — authenticated, but not allowed to do this (a normal user calling an admin endpoint). Logging in again can fix a 401; it won't fix a 403.

Q13. 500 vs 503?

500 Internal Server Error — an unexpected failure, usually a bug; a 500 caused by bad input should have been a 4xx. 503 Service Unavailable — the server is temporarily unable to handle the request (overloaded or in maintenance), often with a Retry-After header.

Requests & Responses (Q14–18)

Q14. What is an endpoint?

The URL of a resource or operation — base URL plus path, such as /api/v1/users/{id}. Combined with a method it defines an operation: GET /users/{id} reads one user.

Q15. What's in an HTTP request?

Method, URL (with path and query parameters), headers (Authorization, Content-Type, Accept) and an optional body.

Learn more: HTTP Requests & Responses

Q16. What's in an HTTP response?

A status code, headers (Content-Type, Location, Set-Cookie, Cache-Control) and an optional body.

Q17. Path parameters vs query parameters?

Path parameters identify a resource and are part of the path: /users/123. Query parameters filter, sort or paginate and come after ?: /users?status=active&page=2. Path parameters are usually required; query parameters optional.

Q18. What are request headers used for?

Metadata about the request: credentials (Authorization, API keys), the body's format (Content-Type), the format wanted back (Accept), caching, and correlation IDs for tracing. A wrong Content-Type typically returns 415; an unsupported Accept returns 406.

Data Formats (Q19–21)

Q19. What is JSON and why is it used?

A lightweight, human-readable key–value format with objects, arrays, strings, numbers, booleans and null. It's the default for REST APIs because it's compact and every language parses it easily.

Q20. JSON vs XML?

JSON is lighter and maps directly to objects and arrays; XML is more verbose but supports attributes, namespaces and strict validation with XSD. REST APIs mostly use JSON; SOAP uses XML exclusively.

Learn more: JSON & XML in API Testing

Q21. JSON vs JSON Schema?

JSON is the data; JSON Schema describes what valid data looks like — required fields, types, formats, allowed values. Validating responses against a schema catches contract changes (a renamed or removed field) that value checks miss.

then().body(matchesJsonSchemaInClasspath("schemas/user.json"));

Learn more: JSON Schema Validation

Authentication (Q22–25)

Q22. What authentication methods do APIs use?

API keys, Basic auth (username and password, Base64-encoded — only over HTTPS), Bearer tokens, OAuth 2.0 (delegated access with scoped tokens), JWT (a common token format) and mutual TLS for system-to-system calls.

Learn more: API Authentication

Q23. Authentication vs authorization?

Authentication — who are you? (login, token). Authorization — what are you allowed to do? (roles, permissions). A failed authentication gives 401; a failed authorization gives 403.

Q24. What is JWT?

A JSON Web Token: header.payload.signature, Base64URL-encoded and signed, not encrypted — anyone can read the payload, but it can't be changed without breaking the signature. It carries claims such as the user ID, roles and expiry (exp) and is sent as Authorization: Bearer <token>.

Q25. How do you test authentication and authorization?

No token (401), invalid or tampered token (401), expired token (401), valid token without permission (403), accessing another user's data by changing an ID (403/404 — a very common real bug), and checking that tokens and passwords never appear in responses or logs.

Postman & Scripting (Q26–28)

Q26. What are Postman variable scopes?

From broadest to narrowest: global, collection, environment, data (from a CSV/JSON file) and local. The narrowest scope wins. Use environments for per-environment values (base URL) and collection variables for values created during a run (tokens, IDs).

Learn more: Postman Environments & Variables

Q27. How do you write assertions in Postman?

pm.test('201 Created', () => pm.response.to.have.status(201));
pm.test('id is a number', () => pm.expect(pm.response.json().id).to.be.a('number'));
pm.test('fast enough', () => pm.expect(pm.response.responseTime).to.be.below(800));

Learn more: Postman Scripting & Assertions

Q28. What is API chaining?

Passing data from one response into later requests — a token from login, an ID from create — so a whole workflow can be tested: login → create → get → update → delete → verify 404.

pm.collectionVariables.set('bookingId', pm.response.json().bookingid);
// next request: GET {{baseUrl}}/bookings/{{bookingId}}

Learn more: Postman API Chaining

Advanced & CI/CD (Q29–30)

Q29. What is a mock server and when is it used?

A fake API that returns predefined responses. It lets front-end and test work continue before the real API exists, and makes hard-to-reproduce cases (a 500, a timeout, an empty list) easy to test. Postman, WireMock and Playwright's route mocking all do this.

Learn more: GraphQL, SOAP & Mock Servers

Q30. How do you run API tests in CI/CD?

Postman collections run with Newman (newman run collection.json -e qa.json -r cli,junit); REST Assured suites run with mvn test. The CI job publishes JUnit results and an HTML report, and a failing test fails the build.

Learn more: Postman Newman CI/CD

Practice answering these out loud against the clock in the API Testing Interview Simulator, and design test cases for real endpoints in the API Testing Scenario Lab.

From the Interview Room

My API testing experience covers CRUD operations, HTTP methods, JSON path, and validating JSON and XML data. On Testsigma, a platform that itself automates API tests, understanding requests, responses and status codes was part of understanding the product. Whatever tool you use, validate the status code, the response structure and the values — not just that the call returned something. Be ready to explain how you validate a response beyond the status code.

📚 Official documentation: MDN: HTTP · ISTQB Glossary of testing terms

FAQs

What should I study first for an API testing interview?

HTTP methods and status codes, request and response structure, authentication, and how you tested APIs in your project — then Postman scripting and REST Assured.

Are Postman questions enough for automation roles?

No — automation and SDET roles also expect REST Assured (or another code-based tool), framework design and CI/CD. See the REST Assured Interview Questions.

What scenario questions are common?

How you'd test a login or payment API, what you'd do when an API returns 200 with an error body, how you'd test pagination, and how you'd verify a delete.

How do I explain API testing in my project?

Name the APIs you tested, the tools, the kinds of tests (functional, negative, auth, schema), how they ran in CI, and one real defect you found.

Next Steps

• The Complete API Testing Tutorial
• The Complete REST Assured Tutorial
• API Testing Project Scenario Questions
• The Complete SDET Interview Guide