Top API Testing Interview Questions

Introduction – Why API Testing Is Important in Interviews

APIs are the backbone of modern applications—connecting web, mobile, backend services, and third-party systems. Because UI layers change frequently, interviewers rely on top api testing interview questions to assess whether candidates truly understand backend behavior, data validation, and integrations.

In interviews, recruiters evaluate whether you can:

• Validate business logic without UI
  
• Understand REST/SOAP fundamentals
  
• Check status codes, headers, schemas
  
• Use tools like Postman, SoapUI, Rest Assured, Python
  
• Explain real-time issues and debugging steps
  

This guide is designed for freshers to experienced testers, with clear answers, examples, and scenarios.

---

What Is API Testing? (Clear & Simple)

API testing verifies that an API:

• Accepts valid requests
  
• Enforces business rules
  
• Returns correct responses and status codes
  
• Handles errors, security, and edge cases
  

Example:
For a login API:

• Valid credentials → 200 OK + token
  
• Invalid credentials → 401 Unauthorized
  
• Missing fields → 400 Bad Request
  

---

REST vs SOAP vs GraphQL (Interview Comparison)

Feature	REST	SOAP	GraphQL
Transport	HTTP	HTTP/SMTP	HTTP
Payload	JSON/XML	XML	JSON
Contract	Optional	WSDL	Schema
Performance	Fast	Slower	Optimized
Usage	Most modern apps	Banking/Legacy	Modern microservices

---

Top API Testing Interview Questions & Answers (100+)

Section A: Fundamentals (Q1–Q20)

1. What is an API?
   A contract that lets systems communicate via requests/responses.
   
2. What is API testing?
   Validating endpoints, payloads, headers, status codes, and business rules.
   
3. API testing vs UI testing?
   API tests backend logic; UI tests presentation.
   
4. HTTP methods?
   GET, POST, PUT, PATCH, DELETE.
   
5. PUT vs PATCH?
   PUT replaces full resource; PATCH updates part.
   
6. Endpoint?
   A URL representing a resource/action.
   
7. Request payload?
   Data sent to the API.
   
8. Response body?
   Data returned by the API.
   
9. Statelessness?
   Each request is independent.
   
10. Idempotency?
    Same request → same outcome.
    
11. Authentication vs Authorization?
    Identity vs permission.
    
12. Common auth types?
    Bearer token, API key, OAuth.
    
13. JWT?
    Signed token with claims.
    
14. API versioning?
    Managing changes via /v1, /v2.
    
15. Schema?
    Defines structure and types.
    
16. Negative testing?
    Invalid inputs/flows.
    
17. Boundary testing?
    Min/max values.
    
18. Regression testing?
    Re-test after changes.
    
19. Smoke testing?
    Basic health checks.
    
20. API chaining?
    Use one response in another request.
    

---

Section B: Status Codes & Validations (Q21–Q35)

Code	Meaning	Use
200	OK	Success
201	Created	Resource created
204	No Content	Success w/o body
400	Bad Request	Invalid input
401	Unauthorized	Invalid auth
403	Forbidden	No permission
404	Not Found	Wrong endpoint
409	Conflict	Duplicate
422	Unprocessable	Rule violation
500	Server Error	Backend failure

21. 
    Is 200 enough?
    No—validate data and rules.
    
22. Header validation?
    Check Authorization, Content-Type, caching.
    
23. Schema validation?
    Ensure structure/types match spec.
    
24. Response time validation?
    Meet SLA limits.
    
25. Pagination testing?
    Pages, counts, boundaries.
    
26. Filtering/sorting?
    Query params behavior.
    
27. Rate limiting?
    Expect 429 after threshold.
    
28. Caching?
    Headers and freshness.
    
29. Concurrency?
    Parallel requests correctness.
    
30. Rollback?
    No partial data on failure.
    
31. Data consistency?
    Same data across systems.
    
32. Error messages?
    Clear and actionable.
    
33. Default values?
    Applied when omitted.
    
34. Enums?
    Reject unsupported values.
    
35. Localization?
    Locale/language responses.
    

---

Section C: Functional Scenarios (Q36–Q60)

36. Test POST create?
    201, body fields, DB side-effects.
    
37. Test GET read?
    200, fields, filters.
    
38. Test PUT/PATCH update?
    Changed vs unchanged fields.
    
39. Test DELETE?
    204 and resource removal.
    
40. Auth failures?
    401/403 for invalid/missing token.
    
41. Idempotency check?
    Repeat PUT.
    
42. Calculation rules?
    Totals, tax, discounts.
    
43. Date rules?
    Past/future constraints.
    
44. File upload APIs?
    Type/size validation.
    
45. Webhooks?
    Trigger and verify callbacks.
    
46. Dependencies?
    Graceful failure handling.
    
47. Retries?
    Transient failures behavior.
    
48. Search APIs?
    Exact vs partial matches.
    
49. Bulk operations?
    Partial success handling.
    
50. Null handling?
    Required vs optional fields.
    
51. Backward compatibility?
    Older clients unaffected.
    
52. ETags?
    Optimistic locking.
    
53. Sorting stability?
    Deterministic order.
    
54. Timezones?
    Correct offsets.
    
55. Precision/rounding?
    Financial accuracy.
    
56. Throttling headers?
    Remaining quota info.
    
57. Cache invalidation?
    Updates clear cache.
    
58. Soft delete?
    Visibility vs removal.
    
59. Feature flags?
    Conditional behavior.
    
60. Observability?
    Trace IDs/log correlation.
    

---

Status Codes + API Validation Example

Request

POST /api/orders

Content-Type: application/json

Authorization: Bearer <token>

{

  “productId”: 501,

  “quantity”: 2,

  “coupon”: “SAVE10”

}

Response

{

  “orderId”: 9001,

  “subtotal”: 200,

  “discount”: 20,

  “tax”: 18,

  “total”: 198,

  “status”: “CREATED”

}

Validations

• Status 201
  
• total = subtotal – discount + tax
  
• quantity > 0
  
• Fields exist & types correct
  

---

Tooling & Automation Snippets

Postman Tests (JavaScript)

pm.test(“201 Created”, () => {

  pm.response.to.have.status(201);

});

pm.test(“Total calculation”, () => {

  const r = pm.response.json();

  pm.expect(r.total).to.eql(r.subtotal – r.discount + r.tax);

});

Rest Assured (Java)

given()

 .contentType(“application/json”)

 .body(payload)

.when()

 .post(“/orders”)

.then()

 .statusCode(201)

 .body(“status”, equalTo(“CREATED”));

Python (requests)

import requests

res = requests.post(url, json=payload, headers=headers)

assert res.status_code == 201

data = res.json()

assert data[“total”] == data[“subtotal”] – data[“discount”] + data[“tax”]

---

Scenario-Based Practical Q&A (15)

1. 200 OK but wrong total—what validations add?
   
2. Coupon applied twice—what rule missed?
   
3. Order created without auth—what defect?
   
4. PATCH updates all fields—issue?
   
5. DELETE returns 200 with body—acceptable?
   
6. Pagination duplicates—cause?
   
7. Overselling stock—how test concurrency?
   
8. Expired token still works—defect?
   
9. 422 vs 400—when each?
   
10. Non-deterministic responses—why?
    
11. Timezone bugs—how catch?
    
12. Search ignores filters—where look?
    
13. Retry causes duplicates—prevention?
    
14. Webhook not fired—verification?
    
15. Schema changed silently—impact?
    

---

How Interviewers Evaluate Your Answer

They look for:

• Clear functional reasoning
  
• Validation beyond status codes
  
• Real examples and edge cases
  
• Tool usage and assertions
  
• Calm debugging approach
  

Tip: Explain what you validate and why.

---

API Testing Interview Cheatsheet

• Validate business rules
  
• Test positive & negative paths
  
• Don’t trust 200 alone
  
• Check schema & headers
  
• Handle edge cases
  
• Use automation where possible
  

---

FAQs – Top API Testing Interview Questions

Q1. Is Postman enough?
Yes for manual testing; automation helps.

Q2. REST or SOAP?
REST is primary; SOAP still relevant.

Q3. Biggest mistake?
Only checking status codes.

Q4. Freshers focus?
Fundamentals + Postman practice.

Q5. How to prepare fast?
Practice real APIs and scenarios.