API Testing Interview Questions and Answers

API testing sends requests straight to the application's interfaces (endpoints) and checks the responses. It checks the status code, headers, body, data correctness, speed and security. It skips the browser and tests the business logic layer.

A good rule is many API tests and fewer UI tests (the test pyramid).

What they are checking: Basic understanding and the value of API tests

Groups: 2xx success, 3xx redirect, 4xx client error, 5xx server error.

What they are checking: Do you know more than 200 and 404?

PUT replaces the whole resource with the data you send. Fields you leave out are reset or removed. It is idempotent (sending it twice gives the same result). PATCH changes only the fields you send. It is not always idempotent (for example "increase by 1").

PUT /users/7        {"name":"Asha","email":"[email protected]","phone":"98..."}   # full object
PATCH /users/7      {"phone":"98..."}                                    # one field

Test points:

• PUT with a missing field
• PATCH with an invalid field
• PUT on an ID that does not exist (404 or create, based on the design). Also check the response code, 200 or 204.

What they are checking: REST rules and what they mean for testing

Authentication answers "who are you?". It checks identity with a password, token, certificate or OTP. Authorization answers "what are you allowed to do?". It checks permissions or roles for the action.

Order: authenticate first, then authorize. In API terms, a missing or invalid token gives 401. A valid token without rights gives 403.

Test ideas: no token, expired token, changed token, and a valid user opening another user's resource (IDOR). Also test role-based actions (admin vs normal user).

What they are checking: Core security words and status codes

Safe means no change to data. Idempotent means calling it many times has the same effect as calling it once. To test it, send the same PUT or DELETE twice and check the final state. Send POST twice to see if it creates a duplicate.

What they are checking: REST basics

• Status code: correct for success and for failure
• Response body: fields, types, values, nulls, schema, and data that matches the DB
• Headers: Content-Type, Cache-Control, CORS, security headers
• Validation: required fields, types, lengths, limits, invalid JSON
• Negative cases: missing or wrong auth, wrong method, bad ID, 404 and 400 messages
• Authorization: roles, access to other users' data
• Business logic and state changes (create then read, update then check, delete then 404)
• Idempotency and concurrency
• Performance: response time, load, rate limiting
• Security: injection, leaking sensitive data, HTTPS
• Error handling: no stack traces, same error format everywhere
• Pagination, sorting, filtering

What they are checking: A full checklist in your head

Postman is a tool to design, send, test and document HTTP requests. A collection is a saved group of requests, optionally in folders. The requests share auth, variables, pre-request scripts and tests. You can run a collection in order with the Collection Runner, and use data files to repeat it with many inputs. You can export it as JSON, share it with a team, and run it in CI with Newman. A normal layout has one folder per module (Auth, Users, Orders). A login request saves a token for the other requests.

What they are checking: Tool basics

Variables help you avoid fixed values. Scopes go from widest to narrowest: global, collection, environment, data (runner file) and local. The narrowest scope wins.

An environment is a set of variables for one target, for example dev, staging, prod. Each has its own baseUrl and login details. You can switch environments without editing requests.

Use: {{baseUrl}}/users/{{userId}}.

Set from scripts:

pm.environment.set("token", pm.response.json().token);
pm.collectionVariables.set("userId", 42);

Never commit real secrets. Use the "secret" variable type or the vault.

What they are checking: Reusable collections

Write JavaScript in the Tests tab (it runs after the response). It uses pm.test and Chai-style pm.expect.

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

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

pm.test("Content-Type is JSON", () => {
  pm.response.to.have.header("Content-Type", /application\/json/);
});

const body = pm.response.json();
pm.test("Has expected fields", () => {
  pm.expect(body).to.have.property("id");
  pm.expect(body.email).to.be.a("string").and.include("@");
  pm.expect(body.items).to.be.an("array").that.is.not.empty;
});

Put one check in each pm.test, so a failure is easy to read.

What they are checking: Can you write assertions without help?

Save the token from the login response, then reuse it through a variable.

Login request, Tests tab:

const res = pm.response.json();
pm.environment.set("token", res.access_token);

Other requests: open the Authorization tab, choose Bearer Token, and use the value {{token}}. Or set it once at collection level so every request inherits it.

A pre-request script on the collection can get a new token when the old one expires. To control the order in a run, use pm.execution.setNextRequest("Get order") (or postman.setNextRequest in older versions).

What they are checking: How data moves between calls

401 Unauthorized (really "unauthenticated") means the server does not know who you are. The token is missing, invalid or expired. The response often includes WWW-Authenticate. 403 Forbidden means the server knows who you are, but you have no permission for this resource.

OpenAPI (formerly Swagger) is a standard way to describe a REST API in a form a machine can read. It lists endpoints, methods, parameters, request and response schemas, and auth. Swagger UI shows it as live documentation where you can try calls.

• Path parameter: points to one resource: /users/42
• Query parameter: filters, sorts and pages: /users?role=admin&page=2
• Request body: the data to create or update, usually JSON, with POST/PUT/PATCH
• Headers: extra information such as auth and content type

• 200 OK: success with a body (GET, or PUT/PATCH that returns the updated resource).
• 201 Created: a new resource was created (POST). It should include a Location header or the created object.
• 204 No Content: success with no body (DELETE, or an update that returns nothing).

500 Internal Server Error means the server failed in an unexpected way. Causes are an unhandled exception, bad data or a failing dependency. If client input triggers it, it is always a bug, because invalid input should give a 4xx code.

A 200 does not mean the answer is right. Also check:

• the response body (fields, types, values, nulls)
• headers and response time
• that data was saved correctly in the database
• side effects (emails, events, other services)
• that no sensitive data is exposed
• that it matches the documentation

Check for these points:

• A steady, structured format (for example { "code": "INVALID_EMAIL", "message": "...", "field": "email" }).
• A message people can read. It should help, but it must be safe.
• The right status code.
• No stack trace, SQL, file paths or internal hostnames.
• The same format on all endpoints.
• Translations, if the API supports them.

• Basic auth: base64 username:password in the header. Use it only over HTTPS.
• API key: a header or query parameter that identifies the client app
• Bearer / JWT: a signed token in Authorization: Bearer <token>. The server keeps no session (stateless).
• OAuth 2.0: access for another app using access and refresh tokens (authorization code and client credentials flows)
• Session cookies: a session ID kept on the server
• mTLS / HMAC signing: used between services

REST Assured is a Java library with a Given-When-Then style. It is usually used with JUnit or TestNG.

Newman is the command line runner for Postman collections. It runs API tests without the GUI, for example in Jenkins or GitHub Actions.

A JSON Web Token has three base64url parts: header, payload (claims such as sub, exp, role) and signature. The server checks the signature, so it can trust the payload without a database lookup. The payload is encoded, not encrypted.

Define the contract (types, required fields, formats, allowed values) and check every response against it. This catches missing fields and type changes that value checks miss.

An operation is idempotent when repeating the same request gives the same final state as running it once. GET, PUT and DELETE are idempotent. POST usually is not.

• Default page size and a custom limit/page. Also try limit=0, a negative value, and a value above the maximum.
• First, middle and last page. A page after the last returns an empty list or 404, as the spec says.
• Total count and links (next, prev) are correct. No rows repeat or go missing across pages when...

A synchronous API returns the final result in the same response. An asynchronous API accepts the job and returns quickly. It often sends 202 Accepted with a job ID or status URL. The result comes later through polling or a webhook (callback).

Use pytest.mark.parametrize to run one test body against a table of invalid inputs and expected codes.

400 Bad Request means the server cannot understand the request. Examples are broken JSON, wrong syntax or a missing parameter. 422 Unprocessable Entity means the request is well formed but fails validation or business rules. Examples are an invalid email value or an age below the minimum. Many APIs use 400 for both. The key is to follow the API's documentation in the same way every time. Also return a structured error body (field, message, code).

CORS (Cross-Origin Resource Sharing) is a browser rule. A web page from origin A can call an API on origin B only if the API allows it with headers such as Access-Control-Allow-Origin. For non-simple requests, the browser first sends a preflight OPTIONS request.

Do not check values that change. Check the type, the format or the link between values. Take IDs from the response that created them and reuse them. For timestamps, check a regex or check that the value is close to now:

Versioning lets an API change without breaking existing clients. The version can be in the URL (/v1/users), a header or the media type. What to test:

• Each supported version returns its documented contract.
• Old clients keep working after a new release (backward compatibility, regression).
• Old versions return deprecation headers and end dates.
• New fields do not break old clients.
• Unknown versions return a clear error.

Contract testing checks that a service provider and its consumers agree on the request and response format. Both do not need to run together. Tools like Pact record what the consumer expects. They then check the provider against it in CI. Integration tests run the real services together. They are slower and fail for many unrelated reasons. Contract tests catch breaking API changes early and cheaply. They work well with a few end-to-end tests.

• Missing required fields, one at a time, and an empty body
• Wrong types (age as a string, email as a number) and nulls
• Invalid formats (bad email, bad date), very long strings, limit values
• Duplicate unique value (email already exists): 409
• Broken JSON, wrong Content-Type (415), unsupported method (405) -...

1. Open the browser dev tools and the Network tab. Compare the failing request with the Postman one (URL, method, headers, body, cookies).
2. Check the Console for CORS errors. Look at the preflight OPTIONS response.
3. Look for a missing or different Authorization, Content-Type, or cookie setting (SameSite,...

Call the API, then query the database for the same record and compare field by field (grey box testing).

Run one chained scenario and check the state at each step:

1. POST create: expect 201 and save the id
2. GET by id: 200 and the same data
3. PUT/PATCH update: 200/204, then GET shows the new values
4. GET list: the resource appears (and filters work)
5. DELETE: 204
6. GET again: 404
7. DELETE again: 404 or 204 (idempotent, no 500 error)

Find the documented limit (for example 100 requests per minute per key). Then:

1. Send requests in a loop until you pass the limit. Confirm 429 Too Many Requests.
2. Check the response headers: Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset.
3. Wait for the time window to end and...

Use the API contract (OpenAPI/Swagger) and a mock server. Postman mock servers, WireMock, Mockoon or json-server return example responses. Testers can then write requests, checks and schema tests. Frontend developers can also work at the same time. Design test cases from the contract, including error responses. When the real service is ready, point the same collection at it by changing the baseUrl environment variable. Then fix any differences between the mock and the real behavior.

Cover the themes of the OWASP API Security Top 10:

• Broken object-level authorization (IDOR): change IDs in the path or body to read another user's data
• Broken authentication: weak tokens, no lockout, token reuse after logout
• Too much data in responses: password hashes or internal fields appear in the...

Measure response time (average and percentiles p90/p95/p99), throughput, error rate and resource use. Tools: JMeter, k6, Gatling, and Postman monitors for simple checks.

First compare the environments: base URL, versions, config and secrets. Then check the test data. Was it already created? Do tests depend on each other or on order? Do parallel runs share data?

• Upload allowed types with multipart/form-data: expect 201, and the stored file can be fetched
• Wrong type, fake extension, empty file, file over the size limit (and exactly at the limit)
• Missing file part, wrong field name, many files
• Auth is required, and a user cannot read other users' files
• File name...

A webhook is an HTTP callback. The system sends it to your URL when an event happens.

• Set up a receiver (webhook.site, a local server with a tunnel, or a mock) and trigger the event.
• Check the payload fields, the headers, and the signature (HMAC). The receiver uses the signature to trust the sender.
• The receiver...

Use mocks to test your own logic in a fast and reliable way. Mock these cases: a normal response, a slow response, error codes (4xx/5xx), a broken body, a timeout, and a partial outage. Add a small set of integration tests against the real sandbox to confirm the contract.