Top 50 API Testing Interview Questions and Answers

Detailed explanation

REST APIs expose resources over standard HTTP methods and usually exchange JSON, so testers focus on status codes, headers, payloads, and resource behaviour. SOAP uses XML envelopes, often with WSDL-defined operations, and may rely on WS-Security. Tooling and assertion strategies differ because SOAP faults and schema rules are more formal than typical REST error bodies.

Practical example

A REST order service returns JSON from GET /orders/12, while a SOAP payment service expects an XML envelope matching the WSDL operation PlacePayment.

Detailed explanation

GET should not change server state and is used for reads. POST creates resources or starts non-idempotent operations. PUT usually replaces an entire resource representation at a known URI. PATCH applies a partial update. DELETE removes a resource. Interview answers should also note safe and idempotent expectations for these methods.

Practical example

GET /users/5 reads a user, POST /users creates one, PUT /users/5 replaces the full profile, PATCH /users/5 changes only email, DELETE /users/5 removes it.

Detailed explanation

Testers validate both the numeric code and whether it matches the business outcome. 2xx confirms successful handling, 3xx indicates the client should follow another location, 4xx shows the request was incorrect or unauthorised, and 5xx points to server-side failure. Strong answers mention common codes such as 200, 201, 204, 400, 401, 403, 404, and 500.

Practical example

A successful create may return 201 Created, a missing resource 404, invalid JSON 400, and a crashed dependency 502 or 503.

Detailed explanation

With PUT, the client usually sends a complete resource body and omitted fields may be cleared or rejected depending on the API contract. PATCH sends only the changes, so unchanged fields remain as-is. Both should be tested for validation, concurrency, and whether repeated calls behave as documented.

Practical example

PUT /products/9 with the full product JSON replaces the item; PATCH /products/9 with {"price": 19.99} updates only the price.

PATCH /products/9 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

{"price": 19.99}

Detailed explanation

Path parameters are usually required identifiers such as /orders/{orderId}. Query parameters appear after ? and commonly control filtering, sorting, search, or pagination. Testers should cover missing, invalid, encoded, duplicated, and oversized values for both styles.

Practical example

GET /orders/1001 uses path parameter 1001; GET /orders?status=open&page=2 uses query parameters for filtering and paging.

Detailed explanation

Request headers tell the server how to interpret the body and who is calling, while response headers describe caching, content type, rate limits, and tracing. Missing or wrong headers can cause 401, 406, 415, or subtle behavioural differences even when the body looks valid.

Practical example

Sending Content-Type: application/xml to a JSON-only endpoint may return 415 Unsupported Media Type.

Detailed explanation

For JSON, testers check objects, arrays, null handling, nested fields, and schema validation. For XML, they also verify namespaces, element order where significant, and schema or WSDL constraints. Both need negative tests for malformed bodies and wrong content types.

Practical example

A create-user JSON body missing email should fail validation; an XML body with an unexpected namespace should be rejected by a SOAP service.

Detailed explanation

APIs expose the system behaviour without browser rendering, locators, or flaky UI timing. They support broader data combinations, negative security checks, and service-level regressions. UI tests remain valuable for user workflows, but API coverage usually gives cheaper feedback for core rules.

Practical example

Discount calculation can be asserted through POST /cart/quote long before a full browser checkout suite runs.

Detailed explanation

A 401 Unauthorized response typically indicates no credentials or bad credentials, and clients may retry after authenticating. A 403 Forbidden response means identity is known but authorisation failed for that resource or operation. Testers must cover both unauthenticated and authenticated-but-unprivileged callers.

Practical example

Calling DELETE /admin/users without a token returns 401; calling it as a valid customer token returns 403.

Detailed explanation

GET, HEAD, and OPTIONS are safe and should not modify resources. Idempotent methods such as GET, PUT, and DELETE should leave the resource in the same state after one or many identical requests. POST is generally neither safe nor idempotent, which is why retries need careful design.

Practical example

Repeating DELETE /orders/5 should leave the order deleted; repeating POST /orders may create multiple orders unless protected by an idempotency key.

Detailed explanation

The client sends Authorization: Basic followed by Base64(username:password). Testers verify successful access with valid credentials, rejection with wrong or missing ones, and that credentials are not logged in clear text by tooling. Because Base64 is not encryption, HTTPS is essential.

Practical example

A monitoring API accepts Authorization: Basic dXNlcjpwYXNz over HTTPS and returns 401 when the password is wrong.

Detailed explanation

If Content-Type is wrong, servers may reject the body with 415. If Accept cannot be satisfied, some APIs return 406. Testers should verify negotiated formats, default behaviour when headers are omitted, and consistency between declared type and actual payload.

Practical example

Sending JSON with Content-Type: application/json and Accept: application/json is the common happy path for REST services.

Detailed explanation

Testers create requests with method, URL, headers, and body, then write test scripts that assert status, JSON paths, and headers. Collections group related calls, while environments hold variables such as baseUrl and tokens. This supports exploratory checks and repeatable regression suites.

Practical example

A Login request stores jsonData.token in an environment variable that the next Get Profile request reuses.

Detailed explanation

Positive cases use valid authentication, data, and preconditions to verify status, payload, and side effects. Negative cases cover missing fields, wrong types, expired tokens, unsupported methods, and boundary values. Both are needed because APIs must succeed correctly and fail predictably.

Practical example

Positive: create order with valid cart returns 201; negative: empty cart returns 400 with a clear error code.

Detailed explanation

Cookie-based sessions are common in browser apps and may include HttpOnly and Secure flags. Token-based APIs often use Bearer JWTs that clients attach manually, which suits mobile and service-to-service calls. Testers must understand expiry, revocation, CSRF implications for cookies, and token leakage risks.

Practical example

A web app may authenticate with a session cookie, while a mobile client calls APIs with Authorization: Bearer <jwt>.

Detailed explanation

A JWT usually contains claims such as subject, roles, and expiry. Testers check that protected endpoints accept valid tokens, reject missing or malformed ones, and deny expired or unsigned tokens. They should also confirm that role claims affect authorisation outcomes.

Practical example

After login returns a JWT, GET /me with Authorization: Bearer <jwt> returns the profile, while an expired token returns 401.

GET /me HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Detailed explanation

Common flows include authorisation code for user-facing apps and client credentials for service accounts. Testers validate token issuance, scopes, refresh behaviour, and that APIs enforce insufficient-scope errors. Understanding redirect URIs, client IDs, and token lifetimes is essential for realistic test setup.

Practical example

A reporting service uses the client-credentials flow to get an access token with reports:read before calling GET /reports.

Detailed explanation

Keys are simpler than OAuth but usually identify the client rather than fine-grained user consent. Testers verify acceptance of active keys, rejection of invalid or revoked ones, and that keys are not exposed in logs or public repositories. Prefer header-based keys over query strings when possible.

Practical example

A weather client sends X-API-Key: abc123 and receives 401 after the key is revoked in the developer portal.

Detailed explanation

Networks and clients retry requests, so duplicate POSTs can create duplicate orders unless the API protects them. Testers verify documented idempotent methods and any idempotency-key behaviour for non-idempotent operations. Assertions should include final resource state, not only the last HTTP response.

Practical example

Sending the same POST /payments twice with Idempotency-Key: pay-77 creates one payment and returns the original result on retry.

Detailed explanation

Offset/limit and cursor-based pagination behave differently under concurrent inserts. Testers check default page size, maximum limits, next/previous links, and that no items are skipped or duplicated across pages. Boundary cases such as page=0 or an unknown cursor should return clear errors.

Practical example

GET /products?page=1&limit=20 returns 20 items and a next link; page=999 returns an empty list or a documented error.

Detailed explanation

Rate limits protect services from abuse and overload. Testers confirm thresholds per key or user, response headers such as Retry-After or X-RateLimit-Remaining, and that legitimate traffic recovers after the window. Care is needed so rate-limit tests do not disrupt shared environments.

Practical example

After 100 requests per minute, the 101st call returns 429 with Retry-After: 30.

Detailed explanation

Browsers send preflight OPTIONS requests for many cross-origin calls and enforce Access-Control-Allow-Origin and related headers. API testers using Postman may miss CORS failures that only appear in browsers. Validate allowed origins, methods, headers, and credentialed request behaviour.

Practical example

A React app on https://shop.example.com fails to call the API until Access-Control-Allow-Origin includes that origin.

Detailed explanation

Instead of only testing a fully integrated system, consumer-driven contracts capture what a client expects from an API. Provider verification checks that the real service still satisfies those expectations. This catches breaking changes early when teams own different services.

Practical example

A mobile team publishes expectations for GET /orders/{id}; the orders service CI fails if required field estimatedDelivery is removed.

Detailed explanation

Beyond checking a few values, schema assertions catch missing fields, type changes, and unexpected nulls. They are especially useful for regression suites and contract alignment. Schemas should be versioned and reviewed when intentional API changes occur.

Practical example

A test fails when orderTotal changes from number to string even though HTTP 200 is still returned.

{
  "type": "object",
  "required": ["id", "status", "total"],
  "properties": {
    "id": { "type": "string" },
    "status": { "type": "string" },
    "total": { "type": "number" }
  }
}

Detailed explanation

A collection can encode a workflow with pre-request scripts, tests, and variable chaining. Separate environments for local, QA, and staging keep the same tests portable. This reduces duplication and makes handoffs between explorers and automation clearer.

Practical example

One collection runs against QA by selecting the QA environment where baseUrl and adminToken differ from staging.

Detailed explanation

Teams export a collection and environment, then run Newman in build agents to assert API health on every change. CI can fail the pipeline on assertion errors and publish HTML or JUnit reports. Secrets should come from CI variables rather than committed environment files.

Practical example

A pull request job runs newman run checkout.postman_collection.json -e qa.postman_environment.json and fails if any test script fails.

newman run checkout.postman_collection.json \
  -e qa.postman_environment.json \
  --reporters cli,junit \
  --reporter-junit-export newman-results.xml

Detailed explanation

It integrates well with JUnit or TestNG and supports authentication helpers, path and query params, and JSON path assertions. Teams often wrap common setup such as base URI and auth in request specifications. This makes API regression suites maintainable in Java-centric stacks.

Practical example

given().auth().oauth2(token).when().get("/orders/12").then().statusCode(200).body("status", equalTo("PAID"));

given()
    .header("Authorization", "Bearer " + token)
    .when()
    .get("/orders/{id}", 12)
    .then()
    .statusCode(200)
    .body("status", equalTo("PAID"));

Detailed explanation

Status alone can hide wrong payloads, and body checks alone can hide incorrect caching or content-type headers. Good tests verify business values, schema shape where useful, and correlation or rate-limit headers when they matter. Choose assertions that prove the risk under test.

Practical example

After creating a refund, assert 201, refundId present, Amount matches, and Location header points to the new resource.

Detailed explanation

Authentication failures usually produce 401 responses for missing or invalid credentials. Authorisation failures produce 403 or equivalent business errors when identity is valid but permissions are insufficient. Testers need matrices of roles, tenants, and object ownership to catch privilege escalation.

Practical example

A support agent can authenticate successfully but still receive 403 when deleting another tenant's billing configuration.

Detailed explanation

Stubs return canned responses for downstream systems such as payment gateways or identity providers. This improves speed and determinism, but over-mocking can hide real contract drift. Use mocks for unit and component API tests, and reserve selected integrated environments for true end-to-end confidence.

Practical example

An orders service test stubs the payment provider to return success and decline scenarios while still exercising real order persistence.

Detailed explanation

Hard-coded hosts and secrets make suites fragile and unsafe. Use environment variables, config files, or tool-specific environments, and keep secrets in a vault or CI secret store. Also account for data differences, such as seeded users that exist only in QA.

Practical example

The suite reads BASE_URL and API_TOKEN from CI secrets, then runs the same checkout smoke against QA or staging.

Detailed explanation

REST testing centres on resources, methods, and status codes. GraphQL testing focuses on query shape, field availability, error arrays, mutations, and over-fetching or under-fetching behaviour. Authorization may be field-level, so negative tests must target sensitive fields, not only endpoints.

Practical example

A GraphQL query requests { order(id:"12") { id total } } on POST /graphql and asserts data.order.total without fetching unused fields.

{
  "query": "query GetOrder($id: ID!) { order(id: $id) { id status total } }",
  "variables": { "id": "12" }
}

Detailed explanation

Webhooks are server-to-server callbacks triggered by events such as payment completed. Testers validate event filtering, signing secrets, timeout behaviour, retry schedules, and that duplicate deliveries do not corrupt state. Local tunnels or mock receivers help during development.

Practical example

After marking an invoice paid, the billing system POSTs invoice.paid to the partner URL with a valid HMAC signature.

Detailed explanation

URI versioning uses paths such as /v1/orders. Header or Accept-based versioning keeps URLs stable but must be asserted explicitly. Testers verify backward compatibility promises, migration behaviour, and that deprecated versions still meet documented support windows.

Practical example

GET /v1/orders/5 and GET /v2/orders/5 may return different schemas; automation should pin the intended version per suite.

Detailed explanation

Upload endpoints often accept multipart/form-data with file parts and additional fields. Testers cover allowed extensions, oversized files, empty files, wrong content types, and concurrent uploads. Also confirm that downloaded or retrieved content matches what was uploaded.

Practical example

POST /kyc/documents with a PDF under the size limit returns 201; a 50 MB executable returns 400 or 415.

POST /kyc/documents HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
Content-Type: multipart/form-data; boundary=----boundary

------boundary
Content-Disposition: form-data; name="file"; filename="id.pdf"
Content-Type: application/pdf

%PDF-1.4 ...
------boundary--

Detailed explanation

An OpenAPI document is a machine-readable contract for paths, methods, auth, and payload schemas. Teams use it for exploratory testing, mock servers, schema validation, and drift detection against implemented behaviour. Testers should still add business scenarios the spec alone may not express.

Practical example

A CI step fails when the live /checkout response no longer matches the published OpenAPI schema for PaymentIntent.

Detailed explanation

Caching can improve performance but may serve stale data if misconfigured. Testers verify Cache-Control directives, 304 Not Modified behaviour with If-None-Match, and that authenticated or highly dynamic responses are not cached inappropriately. Private versus shared cache rules are especially important.

Practical example

GET /catalog/categories returns ETag: "v42"; a later request with If-None-Match: "v42" receives 304 when unchanged.

Detailed explanation

Connect and read timeouts prevent tests from blocking forever on dead services. Retries can help with transient 502/503 or network blips, but retrying non-idempotent POSTs may create duplicates. Automation should distinguish flaky infrastructure from deterministic application defects.

Practical example

A client retries GET /health three times with exponential backoff, but never auto-retries POST /payments without an idempotency key.

const response = await fetch(`${baseUrl}/orders/${id}`, {
  method: "GET",
  headers: { Authorization: `Bearer ${token}` },
  signal: AbortSignal.timeout(5000),
});
if (!response.ok) throw new Error(`Unexpected status ${response.status}`);
const order = await response.json();
expect(order.status).toBe("PAID");

Detailed explanation

After repeated downstream errors, the breaker opens and short-circuits calls until a trial period succeeds. Testers may observe sudden 503s or fallback responses that are protective rather than random bugs. Understanding this pattern helps diagnose intermittent failures and design chaos or resilience tests carefully.

Practical example

When the pricing service is down, checkout returns a fallback 503 quickly instead of waiting 30 seconds on every attempt.

Detailed explanation

The client sends a unique key with a POST; the server stores the first result and replays it for duplicate keys. Testers verify same-key retries return the original outcome, different keys create separate operations, and conflicting payloads with a reused key are rejected. Key expiry behaviour also matters.

Practical example

Two POST /charges requests with Idempotency-Key: charge-9 create one charge; a third with charge-10 creates another.

POST /charges HTTP/1.1
Host: api.example.com
Content-Type: application/json
Idempotency-Key: charge-9
Authorization: Bearer <token>

{"amount": 2500, "currency": "USD"}

Detailed explanation

Content negotiation selects response formats based on client preferences and server capabilities. Testers should validate JSON, XML, or other supported types, quality factors when present, default behaviour with no Accept header, and clear 406 or 415 failures. Versioned media types may also encode API versions.

Practical example

Accept: application/xml returns XML; Accept: application/json returns JSON; Accept: text/plain may return 406.

Detailed explanation

Create, update, and delete operations should leave the system in the expected state. Prefer verifying through public GET APIs when possible to stay black-box, and use direct DB assertions when eventual consistency, hidden side tables, or audit records matter. Always clean up or isolate test data.

Practical example

After POST /users, assert GET /users/{id} and confirm the users table row exists with the expected email hash and status.

Detailed explanation

Flakiness appears when tests depend on leftover records, eventual consistency without polling, or third-party instability. Stabilise with unique test data, deterministic fixtures, explicit readiness checks, retries only for known transient infrastructure, and quarantine noisy tests until root-caused. Logging correlation IDs speeds diagnosis.

Practical example

A test that searches for user John fails in parallel runs; switching to user-${uuid} and waiting for indexing removes the flake.

Detailed explanation

Attackers send crafted strings through query params, headers, and bodies. Testers attempt classic payloads, oversized inputs, unexpected content types, and nested JSON bombs where relevant. Successful security tests show safe rejection or neutralisation without data leakage in errors.

Practical example

Sending name=' OR '1'='1 into a search endpoint should not return all rows or expose SQL exception details.

Detailed explanation

In hypermedia-driven REST, a response may include links such as self, cancel, or payment so clients discover affordances dynamically. Testers verify that links appear for valid states, disappear when actions are illegal, and that following them works. Many APIs skip strict HATEOAS, so confirm whether it is part of the contract before over-investing.

Practical example

GET /orders/55 returns links.cancel when status is CREATED, and omits it after the order is shipped.

Detailed explanation

Model the business flow as dependent API calls with shared data such as cartId and paymentIntentId. Validate intermediate calculations, tax and discount rules, payment outcomes, and the final order read model. Include negative branches like payment decline and stock exhaustion, and clean up or use disposable accounts.

Practical example

Login, add SKU-100 to cart, apply coupon SAVE10, create payment intent, confirm payment, then GET /orders/{id} expecting PAID and discounted total.

const token = await login(user);
const cart = await addToCart(token, { sku: "SKU-100", qty: 1 });
const quote = await applyCoupon(token, cart.id, "SAVE10");
const payment = await createPayment(token, quote.id);
await confirmPayment(token, payment.id);
const order = await getOrder(token, payment.orderId);
expect(order.status).toBe("PAID");
expect(order.total).toBe(quote.total);

Detailed explanation

CI should install dependencies, obtain credentials from a secret store, smoke-check service health, then run Newman, REST Assured, Playwright API tests, or similar. Separate fast PR checks from heavier nightly suites. Quarantine known flakes, keep artefacts such as logs and JUnit XML, and avoid depending on fragile shared data.

Practical example

A PR workflow deploys an ephemeral QA stack, runs contract plus checkout smoke APIs, uploads junit results, and blocks merge on failure.

Detailed explanation

Pick a few business-critical reads and writes, define modest concurrency, and assert thresholds for p95 latency, error rate, and saturation signals. Keep the smoke short enough for CI or nightly runs, and escalate to dedicated performance tests for capacity planning. Baseline results so regressions are obvious.

Practical example

Nightly job sends 20 virtual users to GET /search and POST /cart/items for five minutes and fails if p95 exceeds 500 ms or errors exceed 1%.

Detailed explanation

Shared static users cause cross-test interference and flaky failures. Use factories or APIs to create data with unique identifiers, seed only immutable reference data, and delete or expire records afterward. For parallel runs, isolate by tenant, prefix, or dedicated schemas. Document dependencies that cannot be created through public APIs.

Practical example

Each checkout test creates customer-e2e-${uuid}@mail.test, seeds a wallet balance via an internal fixture API, then deletes the customer in teardown.

Detailed explanation

Object-level authorisation bugs occur when APIs check login but not ownership. Build a matrix of tokens and resource IDs across users and roles, including horizontal access between peers and vertical access to admin resources. Confirm error responses do not reveal whether the object exists if that is part of the threat model, and automate the checks in CI for every protected resource type.

Practical example

User A's token calling GET /accounts/B-9981 must not return balances; the suite also tries PATCH and DELETE on foreign account IDs.