API Testing Interview Questions and Answers PDF: 30 Questions to Revise

1. Open this article on a laptop or desktop.
2. Press Ctrl+P (Windows/Linux) or Cmd+P (Mac).
3. Choose Save as PDF as the destination and click Save.

On a phone, use the browser's Share or menu button and pick Print, then Save as PDF.

If you want more questions in a designed document, these PDFs are in our library. The first pages of each can be previewed free before you decide:

• 100 API Testing Interview Questions (22 pages): a wide question bank for freshers and juniors.
• 200 API Testing Interview Questions & Detailed Answers (35 pages): longer answers for experienced testers.
• API Testing Real-Time Interview Scenarios (22 pages): "how would you test this?" style questions.
• REST Assured Interview Questions: 100 Q&A (65 pages): for automation roles using Java.

Option A is enough for a quick revision. Choose a Vault PDF only if you want more volume or depth.

Answer: API testing checks an application's business logic directly through its interface, by sending requests and checking the responses, without using the UI. You check status codes, response body, headers, response time, error handling and security. It finds bugs earlier and runs much faster than UI tests.

Answer: REST is an architectural style for APIs. Resources are identified by URLs, you act on them with standard HTTP methods, requests are stateless (each one carries everything the server needs), and data is usually sent as JSON.

Answer: SOAP is a protocol that uses XML messages with a strict contract (WSDL) and built-in standards such as WS-Security. REST is a style, lighter, usually JSON, and works directly over HTTP methods. Most modern web and mobile APIs are REST; SOAP is still common in banking and older enterprise systems.

Answer:

Answer: Sending the same request once or many times leaves the server in the same state. Deleting order 55 twice still means order 55 is gone (the second call may return 404, but the state is the same). POST is not idempotent: sending it twice usually creates two records, which is why payment APIs often use an idempotency key.

Answer: A path parameter identifies one resource: /users/42. A query parameter filters, sorts or pages a list: /users?role=admin&page=2. Our guide on headers, query and path params covers this in detail.

Answer: 1xx informational, 2xx success, 3xx redirection, 4xx client error (the request is wrong), 5xx server error (the server failed on a valid request).

Answer: 200 OK, 201 Created (after POST, often with a Location header), 204 No Content (success with no body, common after DELETE), 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Content, 429 Too Many Requests, 500 Internal Server Error, 502 Bad Gateway and 503 Service Unavailable.

Answer: 401 means the server doesn't know who you are: the token is missing, wrong or expired. 403 means it knows who you are, but you are not allowed to do this, for example a normal user calling an admin endpoint.

Answer: 400 is for a request the server can't understand, such as broken JSON. 422 means the syntax is fine but the content fails validation, such as an email field with no "@". Teams differ, so check the API's own documentation.

Answer: The body (correct values, data types, required fields, no extra sensitive data), headers (Content-Type, caching, security headers), response time, and that the data really changed in the system, for example by calling GET after a POST.

Answer: A JSON Schema describes the expected shape of a response: fields, types, required keys and formats. Validating against it catches contract breaks (a field renamed, a number sent as a string) in one check instead of dozens of assertions.

Answer: Authentication proves who you are (login, token). Authorisation decides what you may do (roles, permissions). A strong test plan checks both: an invalid token returns 401, and a valid token for the wrong role returns 403.

Answer: Common ones are API keys (sent in a header), Basic auth (Base64 username and password, only safe over HTTPS), Bearer tokens such as JWT, and OAuth 2.0, where a client gets an access token from an authorisation server. Our API authentication notes go deeper.

Answer: A JSON Web Token has three Base64URL parts: header, payload (claims such as user id and expiry) and signature. Test that an expired token is rejected, a token with a changed payload is rejected because the signature no longer matches, and that the payload contains no secrets, since anyone can decode it.

Answer: Call endpoints without a token; access another user's record by changing the id (broken object-level authorisation, the top risk in the OWASP API Security Top 10); send very long or malicious input; check that error messages don't leak stack traces; and check rate limiting returns 429.

Answer: In the request's Scripts tab (post-response) using the pm API:

pm.test('status is 200', () => {
  pm.response.to.have.status(200);
});
pm.test('returns the user', () => {
  const body = pm.response.json();
  pm.expect(body.id).to.eql(42);
  pm.expect(body.email).to.include('@');
});

Answer: Save it to a variable in the first request's script, then use {{variableName}} in the next request:

const token = pm.response.json().token;
pm.environment.set('authToken', token);
// next request header: Authorization: Bearer {{authToken}}

Answer: Global variables apply everywhere in a workspace. Collection variables belong to one collection. Environment variables change with the environment you pick (dev, staging), so the same requests can run against different servers. Keep secrets out of shared collections.

Answer: Export the collection and environment and run them with Newman or the Postman CLI in the pipeline, which returns a failing exit code when a test fails. The Top 30 Postman Interview Questions PDF covers more Postman questions.

Answer: A Java library for testing REST APIs with a readable given / when / then style. It handles requests, JSON and XML parsing and assertions, and works with TestNG or JUnit.

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

Answer: Set the content type and pass a body, usually a POJO or a Map that REST Assured serialises:

Map<String, Object> user = Map.of("name", "Asha", "role", "tester");
int id = given().contentType(ContentType.JSON).body(user)
    .when().post("/users")
    .then().statusCode(201)
    .extract().path("id");

Answer: Reusable settings (base URI, headers, auth, expected content type) built once with RequestSpecBuilder and ResponseSpecBuilder, so tests don't repeat them.

Answer: Config per environment, a client layer that wraps endpoints, POJOs for request and response bodies, test data builders, specifications for shared settings, tests grouped by feature, reports, and a CI job. Our REST Assured course builds one from scratch.

Answer: Use the json-schema-validator module: .body(matchesJsonSchemaInClasspath("user-schema.json")). Keep schema files next to the tests so a contract change shows up as a clear failure.

Answer: It checks that a provider API and its consumers agree on requests and responses. In consumer-driven contract testing (for example with Pact), the consumer records what it expects and the provider's build verifies it, so a breaking change is caught before deployment.

Answer: When the real dependency is unavailable, slow, costly (a payment gateway) or hard to put into an error state. Tools such as WireMock or Postman mock servers return fixed responses. Keep a smaller set of tests against the real service so mocks don't hide real problems.

Answer: In functional tests, assert a reasonable response time. For load, use a tool such as JMeter or k6 to simulate many users and measure response times (p95, p99), throughput and error rate. Only load-test environments you own or have permission to test.

Answer: Positive: valid data returns 201, the body has an id, and GET by that id returns the same data. Negative: missing required fields, wrong types, invalid email and duplicate email (409). Boundary: minimum and maximum lengths. Security: no token (401), wrong role (403), and the password never returned in the response. Also check the response time and that the Content-Type is JSON.

Answer: Capture the actual request and response in the browser's Network tab. Compare the response body with the expected data and the API documentation. If the API data is wrong, check the database and the server logs; if the data is right, the bug is in how the front end maps or displays it. Report it with the request, response and steps so the right team can fix it.

To practise these questions against a real endpoint, try the free API Playground; its labs grade your requests automatically.