45 API Testing Interview Questions (2026): REST, Postman and Status Codes

Last updated: October 2026

A few years ago, API testing was a "nice to have" skill on a QA resume. Now it's often the first thing interviewers check. Modern apps are a thin UI over dozens of APIs, and bugs found at the API layer are faster to find, faster to fix and cheaper to automate than bugs found through the browser.

API testing interviews are also more practical than most. Expect to open Postman, hit an endpoint, check the response and write a test script, sometimes in the first 15 minutes. This guide covers 45 questions from basics to scenarios, with the Postman and REST Assured snippets interviewers ask you to write.

API testing interview questions: the quick answer

• What gets tested: REST principles, HTTP methods, status codes, headers, request and response bodies (JSON), authentication (API keys, OAuth 2.0, JWT), Postman (collections, environments, scripts), automation (REST Assured or Python requests), and contract and performance testing.
• Typical format: theory questions, then a live task: test a public API in Postman, assert status, body and response time, and chain requests with variables.
• What wins: testing beyond the 200 OK. Validate the schema, negative cases, auth, boundaries, idempotency and error messages.
• Must-know status codes: 200, 201, 204, 400, 401, 403, 404, 409, 422, 429, 500, 502, 503.

API basics (1–14)

1. What is an API?

An Application Programming Interface is a contract that lets one piece of software ask another for data or actions. When a food delivery app shows restaurant menus, it's calling an API that returns menu data, usually as JSON.

2. What is API testing?

Testing the application's business logic directly at the API layer, by sending requests and validating responses (status, body, headers, time) without using the UI. It checks functionality, reliability, performance and security.

3. Why is API testing important?

It finds bugs earlier, before the UI is ready. It runs much faster and is more stable than UI tests, it covers logic the UI may hide, and it's easier to automate in CI. In the testing pyramid, API (service) tests sit between unit tests and UI tests.

4. What is REST?

Representational State Transfer, an architectural style for APIs. Resources are identified by URLs (/users/42), manipulated with standard HTTP methods, and transferred as representations (usually JSON). REST APIs are stateless: each request carries everything the server needs.

5. REST vs SOAP?

6. What are the main HTTP methods?

• GET: read a resource.
• POST: create a resource (or trigger an action).
• PUT: replace a resource completely.
• PATCH: update part of a resource.
• DELETE: remove a resource.
• HEAD / OPTIONS: get headers only / see the allowed methods (used in CORS preflight).

7. What is the difference between PUT and PATCH?

PUT replaces the whole resource with what you send; fields you leave out may be reset. PATCH changes only the fields you send. To update just a user's phone number, PATCH is the right choice.

8. What is the difference between PUT and POST?

POST usually creates a new resource, with the server assigning the ID, and isn't idempotent: sending it twice creates two records. PUT targets a known URL and is idempotent: sending it twice leaves the same result.

9. What does idempotent mean, and which methods are idempotent?

An idempotent request has the same effect whether you send it once or many times. GET, PUT, DELETE, HEAD and OPTIONS are idempotent; POST is not, and PATCH isn't guaranteed to be. Test it: send the same PUT twice and compare the state.

10. What are the HTTP status code classes?

1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error.

11. What do the most common status codes mean?

12. 401 vs 403: what's the difference?

401 means "I don't know who you are": the token is missing, invalid or expired. 403 means "I know who you are, but you're not allowed to do this". Getting these mixed up in an API is itself a bug worth reporting.

13. What are request headers? Name a few important ones.

Key-value metadata sent with a request: Content-Type (format of the body, such as application/json), Accept (format you want back), Authorization (credentials or token), User-Agent, Cache-Control, and custom ones like X-Request-ID for tracing.

14. What are path parameters vs query parameters?

Path parameters identify a specific resource: /users/42. Query parameters filter, sort or paginate: /users?city=Pune&page=2&limit=20. The request body carries data for POST, PUT and PATCH.

Postman (15–24)

15. What is Postman?

A popular tool for sending API requests, organising them into collections, writing tests in JavaScript, managing environments and variables, and running collections from the command line with Newman or the Postman CLI.

16. What are collections and environments?

A collection is a group of saved requests, often organised by feature, with shared scripts and variables. An environment is a set of variables (base URL, tokens, IDs) so the same collection can run against dev, QA, staging or production by switching environments.

17. What are the variable scopes in Postman?

From broadest to narrowest: global, collection, environment, data (from a CSV or JSON file in the runner), and local. When the same name exists in several scopes, the narrowest one wins.

18. How do you write a test in Postman?

In the Scripts → Post-response tab, using pm.test and pm.expect:

pm.test("Status is 200", () => pm.response.to.have.status(200));

pm.test("Response time under 800 ms", () => {
  pm.expect(pm.response.responseTime).to.be.below(800);
});

pm.test("User has the expected email", () => {
  const body = pm.response.json();
  pm.expect(body.email).to.eql("asha@example.com");
  pm.expect(body.id).to.be.a("number");
});

19. How do you chain requests, for example using a token from login in the next request?

Save the value to a variable in the login request's post-response script, then use {{token}} in later requests:

// In the login request
const token = pm.response.json().access_token;
pm.environment.set("token", token);

Then set the next request's header to Authorization: Bearer {{token}}.

20. What is a pre-request script?

JavaScript that runs before a request is sent. It's used to generate dynamic data (timestamps, random emails), compute signatures, or fetch a fresh token.

pm.variables.set("email", `user_${Date.now()}@example.com`);

21. How do you validate a JSON schema in Postman?

const schema = {
  type: "object",
  required: ["id", "name", "email"],
  properties: {
    id: { type: "number" },
    name: { type: "string" },
    email: { type: "string" }
  }
};
pm.test("Schema is valid", () => pm.response.to.have.jsonSchema(schema));

Schema checks catch "the field became a string" or "the field disappeared" bugs that value checks miss.

22. How do you do data-driven testing in Postman?

Use the Collection Runner (or Newman) with a CSV or JSON data file. Each row becomes one iteration, and columns are available as {{columnName}} variables in requests and through pm.iterationData.get("columnName") in scripts.

23. What is Newman?

Postman's command-line collection runner. It lets you run collections in CI pipelines (Jenkins, GitHub Actions) and produce reports:

newman run users.postman_collection.json -e qa.postman_environment.json -r cli,htmlextra

24. What are mock servers in Postman?

Fake endpoints that return saved example responses. They let frontend developers and testers work before the real API is ready, and help test how the client handles specific responses such as errors.

Authentication and security (25–31)

25. What are the common types of API authentication?

API keys (simple, sent in a header), Basic auth (base64 username:password, which needs HTTPS), Bearer tokens, OAuth 2.0 (delegated access with access and refresh tokens), JWT (signed tokens carrying claims) and mutual TLS (both sides present certificates).

26. What is OAuth 2.0?

An authorisation framework that lets an app get limited access to a user's resources without the user's password. Common flows: Authorization Code with PKCE (web and mobile apps) and Client Credentials (service-to-service). The app gets a short-lived access token and often a refresh token.

27. What is a JWT, and what would you test about it?

A JSON Web Token has three base64url parts: header, payload (claims like user ID, role and expiry) and signature. Test: expired tokens are rejected (401), tampered payloads are rejected, a token for user A can't access user B's data, the role claim is enforced, and sensitive data isn't stored in the payload, since anyone can decode it.

28. What security tests do you run on an API?

• Auth: no token, an invalid token, an expired token, and a token from a different user (broken object-level authorisation, the #1 risk in the OWASP API Security Top 10).
• Injection: SQL and NoSQL injection in parameters and bodies.
• Mass assignment: sending extra fields like "role":"admin".
• Rate limiting: do repeated calls return 429?
• Data exposure: does the response include fields it shouldn't, like password hashes?
• HTTPS only, correct CORS settings, and no stack traces in error responses.

29. What is BOLA or IDOR, and how do you test for it?

Broken Object Level Authorization, also called Insecure Direct Object Reference: a user changes an ID in the request (/orders/1001 to /orders/1002) and gets someone else's data. Test it by logging in as user A, then requesting resources that belong to user B. The expected result is 403 or 404.

30. What is rate limiting, and how do you test it?

Limiting how many requests a client can make in a time window, to protect the service. Send requests above the limit and check for 429 Too Many Requests, a Retry-After header if documented, and that the limit resets after the window.

31. What is CORS?

Cross-Origin Resource Sharing: browser rules controlling which websites can call an API from JavaScript. The server responds with headers like Access-Control-Allow-Origin. Test that only approved origins are allowed and that preflight OPTIONS requests work.

Automation and advanced topics (32–39)

32. What tools are used for API test automation?

REST Assured (Java), Python requests with pytest, Playwright's API testing, Karate (BDD-style), SuperTest (Node.js), Postman with Newman, and k6 or JMeter for performance testing.

33. Write a simple REST Assured test.

given()
    .baseUri("https://api.example.com")
    .header("Authorization", "Bearer " + token)
    .contentType(ContentType.JSON)
    .body("{\"name\":\"Asha\",\"email\":\"asha@example.com\"}")
.when()
    .post("/users")
.then()
    .statusCode(201)
    .body("name", equalTo("Asha"))
    .body("id", notNullValue())
    .time(lessThan(1000L));

34. How would you structure an API automation framework?

Separate config (base URLs, environments), API client or service layer (one class per resource), test data builders, tests, and reusable assertions or schema files. Add logging of requests and responses on failure, run in CI on every merge, and publish reports with Allure or Extent Reports.

35. What is contract testing?

Testing that a provider API and its consumers agree on the request and response format. In consumer-driven contract testing (with Pact), each consumer publishes what it expects, and the provider's build verifies it can still meet those expectations. It catches breaking changes before deployment, without slow end-to-end tests.

36. What is the difference between API functional testing and performance testing?

Functional testing checks that responses are correct. Performance testing checks speed and stability under load: response time (p95, p99), throughput, error rate under expected load (load testing), beyond it (stress testing), over hours (soak testing) and with sudden surges (spike testing).

37. How do you test pagination?

Check the default page size, valid page and limit values, the first and last pages, a page beyond the last (expect an empty list, not an error), a limit of 0, negative values and very large limits, no duplicate or missing records across pages, consistent sorting, and correct metadata like total and next links.

38. How do you test an API that depends on another service that isn't ready?

Use mocks or stubs: Postman mock servers, WireMock or MockServer, which return controlled responses including errors and timeouts. Then test the real integration in a later environment.

39. What is GraphQL, and how is testing it different?

A query language where the client asks for exactly the fields it needs from a single endpoint, usually POST /graphql. Differences for testing: errors often come back with HTTP 200 inside an errors array, so check the body, not just the status. Also test query depth and complexity limits, field-level authorisation and introspection settings.

Scenario questions (40–45)

40. How would you test a "create user" API (POST /users)?

• Positive: valid data gives 201, the returned body matches the input, an ID is generated, and GET /users/{id} returns the same user.
• Validation: missing required fields, wrong data types, invalid email, too long values, special characters and Unicode names → 400 or 422 with clear messages.
• Business rules: a duplicate email → 409.
• Security: no token → 401, a normal user creating an admin → 403, extra fields like "role" ignored.
• Other: response time, response schema, headers (Content-Type, Location), and what happens on retry.

41. How would you test a payment API?

Successful payment, insufficient balance, an invalid card or UPI ID, amount boundaries (0, negative, the maximum allowed, decimals), currency handling, idempotency (the same idempotency key twice must not charge twice), timeout and retry behaviour, webhook or callback handling, refunds and partial refunds, audit logs, and that card data is never returned or logged.

42. The API returns 200 OK, but the data is wrong. What do you do?

Compare the response with the database (with an SQL query) and the requirement. Check whether the right environment and test data were used, whether caching is involved, and whether the request had the right filters. Then log a bug with the request, the response, the expected value and the source of truth. A 200 with wrong data is a functional bug, and often a serious one.

43. An API is slow only sometimes. How do you investigate?

Measure first: run repeated calls and look at p50 vs p95 and p99 times. Check whether it's tied to certain inputs (large payloads, specific IDs), time of day, cold caches or downstream dependencies. Use logs and tracing IDs with developers, and run a small load test to see whether it gets worse under concurrency.

44. How do you test a DELETE API?

Delete an existing resource and get 204 (or 200); then GET it and get 404. Delete it again: 404 or 204, depending on the documented idempotent behaviour. Delete without auth (401) or someone else's resource (403/404), check related data is handled (cascade or blocked), and check soft-delete flags if used.

45. What would you check in an API response besides the status code?

Body values against expected data, the JSON schema (types, required fields, no extra sensitive fields), headers (Content-Type, caching, security headers), response time, error message format and clarity, pagination metadata, and side effects, such as whether the record was really created in the database or an event was published.

Common mistakes candidates make

• Checking only the status code.
• Testing only positive cases with "nice" data.
• Not knowing 401 vs 403 or PUT vs PATCH.
• Hard-coding tokens and URLs instead of using environments and variables.
• Ignoring idempotency and retries for payment or order APIs.

A 5-day API testing prep plan

Practice APIs like reqres.in, the Restful Booker API and JSONPlaceholder are free and made for exactly this.

Which roles ask API testing, and what to read next

API testing is core for QA engineers, SDETs, automation testers and backend developers. Build up from our manual testing interview questions, then add Selenium interview questions for UI automation. Backend context helps too: see microservices interview questions.

For your resume, see QA engineer resume examples, and check pay on Weekday's salary pages.

Frequently asked questions

Is API testing manual or automated?

Both. Testers often explore an API manually in Postman first, then automate stable checks with REST Assured, Python, Playwright or Newman so they run on every build.

Is Postman enough for API testing jobs?

For entry-level QA roles, strong Postman skills (scripts, environments, Newman) are often enough. For SDET and automation roles, add a code-based framework like REST Assured or pytest with requests.

What is the difference between API testing and unit testing?

Unit tests check individual functions in isolation and are written by developers. API tests check the behaviour of a deployed service through its HTTP interface, including its integration with the database and other services.

Do I need to know coding for API testing?

Basic JavaScript is enough for Postman scripts. For automation frameworks, you need Java, Python or JavaScript at a working level.

What are the most asked API testing interview questions?

PUT vs PATCH vs POST, status codes (especially 401 vs 403), idempotency, chaining requests in Postman, how to test a POST API, and the REST vs SOAP difference.

Ready for QA and SDET roles? Find testing and automation jobs on Weekday, and check your resume with our free ATS resume checker first.