API Testing Technical Interview Questions

Introduction – Why API Testing Is Important in Technical Interviews

Modern software systems are API-first. Web, mobile, microservices, and third-party integrations all communicate through APIs. As a result, technical interviewers rely heavily on api testing technical interview questions to assess whether candidates truly understand backend behavior—not just UI flows.

In technical rounds, interviewers evaluate whether you can:

• Explain REST/SOAP fundamentals clearly
  
• Validate business logic, not just HTTP status codes
  
• Handle negative cases, edge cases, and security basics
  
• Use tools like Postman, SoapUI, Rest Assured, Python
  
• Reason through real-time production issues
  

This guide is designed for freshers to experienced QA/API engineers, with simple explanations, practical examples, and scenario-based answers.

---

What Is API Testing? (Clear & Simple)

API testing verifies that Application Programming Interfaces:

• Accept valid requests
  
• Enforce business rules
  
• Return correct responses and status codes
  
• Handle errors, performance, and security properly
  

Example (Login API):

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

---

REST vs SOAP vs GraphQL (Technical Comparison)

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

---

API Testing Technical Interview Questions & Answers (100+)

Section A: Fundamentals (Q1–Q20)

1. What is an API?
   A contract enabling systems to 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. Common API types?
   REST and SOAP.
   
5. What is REST?
   An architectural style using HTTP verbs and stateless interactions.
   
6. What is SOAP?
   An XML-based protocol with strict contracts (WSDL).
   
7. Endpoint?
   A URL representing a resource/action.
   
8. Request payload?
   Data sent to the API body.
   
9. Response body?
   Data returned by the API.
   
10. Statelessness?
    Each request contains all needed context.
    
11. Idempotency?
    Same request → same outcome.
    
12. Authentication vs Authorization?
    Identity vs permission.
    
13. Common auth types?
    Bearer token, API key, OAuth, Basic Auth.
    
14. JWT?
    Signed token with claims for stateless auth.
    
15. API versioning?
    Managing changes via /v1, /v2.
    
16. Positive vs negative testing?
    Valid inputs vs invalid/error cases.
    
17. Boundary testing?
    Min/max values.
    
18. Schema?
    Defines structure and data types.
    
19. API chaining?
    Use one response in another request.
    
20. Regression testing?
    Re-test after changes.
    

---

Section B: HTTP Methods & Status Codes (Q21–Q35)

HTTP Methods

Method	Use
GET	Read
POST	Create
PUT	Replace
PATCH	Partial update
DELETE	Remove

Status Codes

Code	Meaning
200	OK
201	Created
204	No Content
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
409	Conflict
422	Rule violation
429	Too Many Requests
500	Server Error

21. 
    Is 200 enough?
    No—validate data and rules.
    
22. Header validation?
    Authorization, Content-Type, caching.
    
23. Schema validation?
    Ensure response structure matches spec.
    
24. Response time testing?
    Meet SLAs.
    
25. Pagination testing?
    Pages, boundaries, totals.
    
26. Filtering/sorting?
    Query params correctness.
    
27. Rate limiting?
    Expect 429 beyond thresholds.
    
28. Caching?
    Headers and performance gains.
    
29. Concurrency?
    Parallel requests correctness.
    
30. Rollback?
    No partial data on failure.
    
31. Data consistency?
    Same data across systems.
    
32. Error messages?
    Clear, non-leaky.
    
33. Default values?
    Applied when omitted.
    
34. Enums?
    Reject unsupported values.
    
35. Localization/timezones?
    Correct formats and offsets.
    

---

Section C: Functional & Advanced Topics (Q36–Q60)

36. Create (POST) validation?
    201, body fields, side-effects.
    
37. Read (GET) validation?
    200, filters, fields.
    
38. Update (PUT/PATCH) validation?
    Changed vs unchanged fields.
    
39. Delete validation?
    204 and resource removal.
    
40. Auth failures?
    401/403 for missing/invalid token.
    
41. Idempotency checks?
    Repeat PUT/PATCH.
    
42. Business calculations?
    Totals, tax, discounts.
    
43. Date rules?
    Past/future constraints.
    
44. File uploads?
    Type/size checks.
    
45. Webhooks?
    Trigger and verify callbacks.
    
46. Dependencies?
    Graceful failure handling.
    
47. Retries?
    Transient error behavior.
    
48. Search APIs?
    Exact/partial matches.
    
49. Bulk operations?
    Partial success handling.
    
50. Null handling?
    Required vs optional.
    
51. Backward compatibility?
    Older clients unaffected.
    
52. ETags/optimistic locking?
    Prevent lost updates.
    
53. Sorting stability?
    Deterministic order.
    
54. Precision/rounding?
    Financial accuracy.
    
55. Throttling headers?
    Remaining quota.
    
56. Cache invalidation?
    Updates clear cache.
    
57. Soft delete?
    Visibility vs removal.
    
58. Feature flags?
    Conditional behavior.
    
59. Observability?
    Trace IDs/log correlation.
    
60. Contract testing?
    Provider–consumer agreement.
    

---

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
  
• Schema and headers correct
  

---

Tooling & Automation Snippets

Postman (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);

});

SoapUI (XPath)

//status = ‘CREATED’

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 data—what checks add?
   
2. Coupon applied twice—what rule missed?
   
3. Order created without auth—defect?
   
4. PATCH updates all fields—issue?
   
5. DELETE returns body—acceptable?
   
6. Pagination duplicates—cause?
   
7. Overselling stock—test concurrency how?
   
8. Expired token still works—risk?
   
9. 422 vs 400—when to use?
   
10. Non-deterministic responses—why?
    
11. Timezone bugs—how catch?
    
12. Search ignores filters—where look?
    
13. Retries cause duplicates—prevention?
    
14. Webhook not fired—verify how?
    
15. Schema changed silently—impact?
    

---

How Interviewers Evaluate Your Answer

They look for:

• Clear technical reasoning
  
• Validation beyond status codes
  
• Real examples and edge cases
  
• Tool usage and assertions
  
• Calm, logical debugging
  

Tip: Explain what you validate and why.

---

API Testing Technical Interview Cheatsheet

• Validate business rules
  
• Test positive & negative paths
  
• Don’t trust 200 alone
  
• Check schema & headers
  
• Handle edge cases
  
• Automate critical paths
  

---

FAQs – API Testing Technical Interview Questions

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

Q2. REST or SOAP—what to focus on?
REST primarily; SOAP basics are valuable.

Q3. Biggest mistake candidates make?
Only checking status codes.

Q4. Freshers vs experienced focus?
Freshers: fundamentals; Experienced: scenarios & automation.

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