interviewDeck

Your one-stop platform to prepare, practice and ace your interviews.

Loading your questions…

interviewDeck

All Questions

Filters & tools

API Testing Interview Questions and Answers

20 hand-picked API Testing interview questions with detailed answers. Open the interactive version above to search, filter by difficulty, run code, bookmark questions and track your progress.

What is API testing? Why is it important for SDETs?

API testing validates application programming interfaces — usually REST/HTTP services — by sending requests and checking responses without (or before) using the UI.

It is important because APIs are the backbone of modern apps: faster than UI tests, more stable, and they catch business-logic and contract bugs early.

Explain common HTTP methods and status codes used in API testing.

Methods: GET (read), POST (create), PUT/PATCH (update), DELETE (remove).

Status codes: 2xx success (200/201), 4xx client error (400 bad request, 401 unauthorized, 403 forbidden, 404 not found), 5xx server error (500).

GET    /api/orders/123     → 200 + order JSON
POST   /api/orders         → 201 + created id
DELETE /api/orders/123     → 204 or 200

How do you use Postman for API testing?

In Postman you create requests (method, URL, headers, body), organise them into Collections, and use Environments for variables like base URL and tokens.

You can add Tests (JavaScript assertions) on status/body, chain requests with variables, and run collections via Collection Runner or Newman in CI.

pm.test('status is 200', () => {
  pm.response.to.have.status(200);
});
pm.test('has orderId', () => {
  const json = pm.response.json();
  pm.expect(json.orderId).to.be.a('string');
});

How do you test API authentication and authorization?

Authentication = who you are (login/token). Authorization = what you are allowed to do (roles/permissions).

Test with valid token, missing token, expired/invalid token, and a valid user calling a forbidden resource (e.g. normal user hitting admin API).

Authorization: Bearer <access_token>

What do you validate in an API response?

  • Status code matches the scenario.
  • Response time is within an agreed limit (basic performance signal).
  • Headers like Content-Type.
  • Body: required fields present, correct types/values, error structure on failures.
  • Contract: no unexpected breaking field changes when relevant.
  • Side effects: DB/UI state updated if the API creates/updates data.
pm.test('order status is CREATED', () => {
  pm.expect(pm.response.json().status).to.eql('CREATED');
});

How do you design an end-to-end API test flow (example: ecommerce order)?

Chain APIs in business order and pass data between calls: authenticate → create customer/cart → place order → fetch order → (optional) cancel/update → assert final state.

Store dynamic IDs/tokens from each response and reuse them. Clean up test data when possible so runs stay independent.

1) POST /auth/login          → token
2) POST /cart/items          → cartId
3) POST /orders              → orderId
4) GET  /orders/{{orderId}}  → status=CREATED

REST vs SOAP — what should a tester know?

REST APIs usually use HTTP + JSON, are resource-based, and are most common today. SOAP uses XML envelopes and strict WSDL contracts — still seen in enterprise/telecom integrations. Testing REST focuses on HTTP semantics; SOAP focuses on operations and XML schemas.

REST: GET /orders/1  → JSON
SOAP: XML <GetOrder> request/response

What is idempotency in APIs? Why test it?

An idempotent operation can be repeated with the same result — e.g. GET, PUT, DELETE ideally. POST create is often not idempotent (two calls → two orders) unless the API uses an idempotency key.

POST /orders twice without key → 2 orders (bug risk)
POST /orders with Idempotency-Key → same order returned

Which HTTP headers matter most in API testing?

Common critical headers: Authorization, Content-Type, Accept, correlation/request IDs, and sometimes If-Match/idempotency keys. Wrong Content-Type often yields 415; missing auth yields 401.

Content-Type: application/json
Authorization: Bearer <token>
Accept: application/json

Path parameters vs query parameters — how do you test them?

Path params identify a resource (/orders/{orderId}). Query params filter/sort/page (/orders?status=OPEN&page=2). Test valid values, missing required params, invalid types, and empty/unknown filters.

GET /orders/ORD-1
GET /orders?status=CANCELLED&page=1&size=20

How do you test request body / schema validation?

Send valid payloads and systematic invalid ones: missing required fields, wrong types, empty strings, oversized values, extra unexpected fields (depending on API strictness). Expect 400 with clear validation errors — not 500.

POST /orders {"items":[]}           → 400
POST /orders {"items":[{"qty":"x"}]} → 400
POST /orders valid body              → 201

Why is asserting only HTTP status code not enough?

Status can be 200 while body is wrong (incorrect total, missing fields, wrong status enum). Always assert business-critical fields and types. Conversely, body may look fine while status is wrong for the contract.

expect(status).toBe(201)
expect(body.orderId).toBeTruthy()
expect(body.status).toBe('CREATED')

How do you run Postman collections in CI (Newman)?

Newman is the CLI runner for Postman collections. In CI you export collection + environment, run Newman in the pipeline, fail the build on test failures, and publish the HTML/CLI report.

newman run order-api.postman_collection.json \
  -e qa.postman_environment.json \
  --reporters cli,htmlextra

When should you mock dependencies in API testing?

Mock when a dependency is unstable, costly, or outside your control (payment gateway, SMS, third-party KYC). Don’t mock the system under test itself. Use real integrated envs for contract confidence on critical paths when possible.

How do you test pagination, sorting, and filtering?

Verify page size boundaries, page numbers, empty pages, total counts, stable sort order, and filter combinations. Check that no duplicates appear across pages and that invalid page params return 400.

GET /orders?page=1&size=10&sort=createdAt,desc&status=OPEN

What should you validate in API error responses?

Validate status code, stable error code/message structure, field-level validation details when relevant, and that no sensitive internals leak (stack traces, SQL, secrets). Errors should be consistent across endpoints.

{
  "code": "VALIDATION_ERROR",
  "message": "Invalid request",
  "fields": [{"name": "qty", "error": "must be >= 1"}]
}

How do you test API rate limiting / throttling?

Send requests beyond the documented limit and expect throttling responses (often 429) with retry guidance when provided. Confirm legitimate traffic still works below the threshold and that limits apply per user/IP/key as designed.

Burst 100 req/sec → expect 429 after threshold

How do you approach API versioning in testing?

Know how versions are exposed (URL /v1, header, or media type). Test that older supported versions still behave for consumers, and that breaking changes don’t silently land on an existing version. Regression should include critical contracts per supported version.

GET /v1/orders/1
GET /v2/orders/1

How do you test file upload APIs?

Test valid file types/sizes, invalid type, oversize file, empty file, missing multipart field, and auth on upload endpoints. Verify response metadata and that the file is stored/linked correctly (or rejected cleanly).

POST /documents multipart/form-data file=@invoice.pdf

What is API contract testing?

Contract testing verifies that a provider’s API still meets the expectations a consumer relies on (fields, types, status behaviours). It catches breaking changes earlier than full UI e2e, often via schema checks or consumer-driven contract tools.