API testing interview questions

Fundamentals

1. What is API testing and why is it done separately from UI testing?

API testing sends requests directly to the service and checks the responses, without a browser. It is faster and more stable than UI testing, it finds problems earlier (before the UI exists), and it reaches cases the UI never lets a user create, such as a missing field or a wrong data type. A good suite has many API tests and a few UI tests.

2. What are the common HTTP methods and what does each mean?

GET reads, POST creates or triggers an action, PUT replaces a whole resource, PATCH changes part of one, DELETE removes. GET, PUT and DELETE should be idempotent: repeating the same request leaves the system in the same state. POST normally is not.

Likely follow-up: PUT vs PATCH? Send {"name":"Asha"} with PUT and the other fields may be cleared because you replaced the resource. With PATCH only the name changes.

3. Which status codes should every tester know?

4. What is the difference between 401 and 403?

401 means the server does not know who you are (no or invalid credentials). 403 means it knows who you are and you are not allowed to do this. A very common bug is returning 403 for a missing token, or 200 with an error message in the body.

5. What is the difference between authentication and authorization?

Authentication proves identity (a password, a token). Authorization decides what that identity may do (can this user view someone else's order?). Testing authorization means trying to access other users' data with a valid token, which is called testing for broken object-level access.

What to check

6. What do you validate in an API response?

The status code, the response body (field names, data types, values, required fields present, no extra sensitive fields), headers (Content-Type, caching, Location), response time against a limit, and the effect on the system (did the record really get created in the database or in a follow-up GET). The status code alone is not a test.

7. How would you test a POST /users endpoint?

Valid request returns 201 and the created user, then a GET confirms it. Missing each required field returns 400 or 422 with a helpful message. Wrong data types (a number where text is expected). Boundary lengths on every string. Duplicate email returns 409. An invalid email format. Very large payload. Special characters and unicode. No token returns 401, wrong role returns 403. Repeating the same request twice. SQL or script text in fields should be stored or rejected safely, never executed.

8. What is idempotency and why does it matter for payments?

An operation is idempotent when doing it twice has the same effect as doing it once. For payments you want that, because a mobile network retry or a double click must not charge a customer twice. APIs achieve it with an idempotency key sent in a header: the server stores the result for that key and returns it again on a retry. Test it by sending the same create request with the same key twice and asserting that only one record exists.

9. How do you test pagination, filtering and sorting?

Request page 1, page 2 and the last page; check that the page size is respected, that no item appears on two pages and none is skipped, that an out-of-range page returns an empty list or a clear error, and that limit=0, negative and huge limits are handled. For sorting, assert the order on the returned values, not just on the first item. For filtering, check that every returned item matches and a filter with no match returns an empty list, not an error.

Authentication

10. How do API key, Basic, Bearer and OAuth 2.0 differ?

An API key is a secret string sent in a header or query string. Basic auth sends username:password encoded in Base64 (encoded, not encrypted, so only safe over HTTPS). A Bearer token (often a JWT) is sent as Authorization: Bearer <token> after the client has logged in once. OAuth 2.0 is a framework for getting that token on behalf of a user without sharing the password, with scopes that limit what the token can do.

11. What would you test around a JWT?

An expired token returns 401, a tampered token (change one character of the payload) returns 401, a token with a different signature is refused, a token for user A cannot read user B's data, logout or password change invalidates the token if the design says so, and sensitive data such as passwords never appears in the payload (a JWT payload is readable by anyone).

Tools and automation

12. How do you use variables and environments in Postman?

Environments hold values that change between systems ({{baseUrl}}, {{token}}) so the same collection runs against dev, test and staging. You set variables from a response in a test script and use them in the next request.

// Tests tab of the login request
const body = pm.response.json();
pm.environment.set("token", body.token);

13. Write a Postman test that checks status, a field and response time.

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

pm.test("returns the user we asked for", () => {
  const user = pm.response.json();
  pm.expect(user.id).to.eql(42);
  pm.expect(user.email).to.match(/@/);
  pm.expect(user).to.not.have.property("password");
});

pm.test("responds within 800 ms", () => pm.expect(pm.response.responseTime).to.be.below(800));

14. Write the same check with Rest Assured.

given()
    .baseUri("https://api.example.com")
    .header("Authorization", "Bearer " + token)
.when()
    .get("/users/42")
.then()
    .statusCode(200)
    .body("id", equalTo(42))
    .body("email", containsString("@"))
    .body("$", not(hasKey("password")))
    .time(lessThan(800L));

To find the path for a nested value such as data.items[0].price, paste a response into the JSON path finder.

15. How do you chain API calls, for example create, read, delete?

Take the id from the create response, store it in a variable, use it in the read call, then delete it in the same test so that the test leaves no data behind and can run again. In Rest Assured, extract it with .extract().path("id"). In Postman, set it as a variable in the tests script.

Judgement

16. The UI shows an error but the API returned 200. Which is the bug?

Probably the API: a 200 with an error message in the body breaks the contract that clients and monitoring tools rely on. Check the API documentation first. If the contract says errors come as 200 with an error code, then the UI is simply showing it, and the documentation is the issue. Either way, ask which behaviour was intended before filing.

17. How do you test an API that depends on another service which is not ready?

Use a mock or stub: a fake server (WireMock, Postman mock server, or a small script) that returns the recorded or agreed responses, including error cases like timeouts and 500s that are hard to produce on the real service. Then, when the real service is ready, run the same tests against it and compare against the contract.

Going deeper

18. What is the difference between REST and SOAP?

REST is an architectural style that uses HTTP methods and URLs for resources, usually with JSON, and relies on the HTTP status codes. SOAP is a protocol with a strict XML envelope, a WSDL contract and built-in standards for security and transactions. REST is lighter and more common for web and mobile; SOAP still appears in banking, insurance and older enterprise systems. For testing SOAP you validate against the WSDL and use tools such as SoapUI.

19. What does "stateless" mean for a REST API, and why does it matter to a tester?

Each request carries everything the server needs; the server keeps no session between requests. So a test can call any endpoint in any order, run in parallel, and be retried. When you find an endpoint that works only after another one was called, the API is hiding state, which makes it harder to test and scale.

20. How do caching headers, ETag and 304 work?

A server can send an ETag (a fingerprint of the response) and Cache-Control rules. The client's next request can include If-None-Match with that ETag; if nothing changed the server answers 304 Not Modified with no body. Test that an unchanged resource gives 304, a changed one gives 200 with a new ETag, and that private data is never cacheable by shared caches (Cache-Control: private or no-store).

21. What is CORS and why do tests in Postman not show CORS errors?

CORS is a browser rule: a page from one origin may call another origin only if the server allows it with headers such as Access-Control-Allow-Origin. Postman and Rest Assured are not browsers, so they ignore it. A CORS problem therefore shows only in browser-based tests. Check the headers (and the preflight OPTIONS response) directly in an API test, or test through the browser.

22. How do you test rate limiting?

Send requests faster than the limit and check that the response becomes 429 Too Many Requests, that a Retry-After header says when to try again, that the limit is per user or key and not shared by everyone, and that the counter resets after the window. Also check that legitimate traffic just below the limit is not blocked.

23. How do you test API versioning and backward compatibility?

Keep a regression set of calls for the old version (/v1/) and run it after every release; adding fields is safe, but removing or renaming a field, changing a type or making an optional field required breaks existing clients. Check that deprecated versions return a deprecation signal and that the old and new versions return consistent data for the same record.

24. What is contract testing and how is it different from schema validation?

Schema validation checks that a response matches a description (types, required fields). Contract testing goes further: the consumer of an API states what it relies on, and the provider's build verifies it keeps that promise (the tool Pact does this). It catches "the provider changed something the consumer used" before release, without running both systems together.

25. How would you validate a response against a JSON schema?

Write the schema once (types, required fields, formats, enums, ranges) and validate every response against it, so you do not write hundreds of one-field assertions.

{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "role": { "enum": ["user", "admin"] }
  },
  "additionalProperties": false
}

In Rest Assured use the json-schema-validator module; in Postman use tv4 or ajv in a test script. additionalProperties: false catches fields that should not be exposed.

26. How do you test a file upload API?

Send a multipart/form-data request with a valid file and check the response and that the file can be retrieved. Then the negative cases: wrong type, empty file, a file over the size limit, a very long or odd file name, the right extension with the wrong content (a .png that is really a script), a missing field, and a request without a token.

27. How do you test an asynchronous API, such as one that returns 202 and processes later?

The first call returns 202 Accepted with a status URL or job id. Poll that URL with a timeout and an interval until the state is complete or failed, then check the result. Never use a fixed sleep. Also test the failure and timeout paths, and what happens if the client asks for the result before it is ready. For webhooks, use a small receiver (or a mock server) that records calls.

28. What is the difference between a mock, a stub and a virtual service?

A stub returns fixed answers. A mock also records and verifies how it was called. A virtual service is a stand-in for a whole dependency (a payment gateway, a third-party API) that behaves like it, including delays and errors. Use them when the real service is not ready, is slow or costs money, and to produce failures (timeouts, 500s) that are hard to create on the real one.

29. Which security problems do you look for in an API?

The common ones: broken object-level authorization (changing an id to read someone else's data), broken authentication (weak tokens, no lockout), excessive data exposure (the response contains fields the client does not need, such as password hashes), mass assignment (sending "role":"admin" in a profile update and having it accepted), missing rate limits, and injection through parameters. You can practise several of these on the ShopLite buggy app.

30. How do you report API performance, and what is a percentile?

Average response time hides the slow requests. Report percentiles: p50 (the typical request), p95 and p99 (the slow tail that real users still hit). "p95 is 800 ms" means 95% of requests were faster than that. Measure under a realistic load with a tool such as JMeter or k6, watch error rate and throughput as well, and compare each run with the last.

Practise it

Open a real response in the JSON tools, find the JSONPath of three different fields and write an assertion for each. Then try the same on a response with a nested array.