Introduction – Why API Functional Testing Matters in Interviews
Modern applications rely on APIs to move data between clients, servers, and third-party services. Because APIs implement business rules (not just transport), interviewers emphasize api functional testing interview questions to assess whether candidates can verify what the API does, not only whether it responds.
In interviews, you’ll be evaluated on your ability to:
- Validate functional correctness of APIs
- Check business rules via requests and responses
- Design positive/negative test cases
- Use tools like Postman, SoapUI, Rest Assured, Python
- Explain real-time failures and debugging steps
This guide targets freshers through experienced testers with clear explanations, samples, and scenarios.
What Is API Testing? (Clear & Simple)
API testing verifies that an API:
- Accepts valid requests
- Enforces business rules
- Returns correct data and status codes
- Handles errors gracefully
Functional API testing focuses on behavior—inputs, processing, and outputs—rather than performance or security alone.
Example:
For an order API, functional testing ensures:
- Stock is reduced after purchase
- Total price includes tax/discount
- Invalid quantities are rejected
REST vs SOAP vs GraphQL (Interview Comparison)
| Feature | REST | SOAP | GraphQL |
| Transport | HTTP | HTTP/SMTP | HTTP |
| Payload | JSON/XML | XML | JSON |
| Contract | OpenAPI | WSDL | Schema |
| Flexibility | High | Low | Very High |
| Typical Use | Web/Mobile | Banking/Legacy | Modern APIs |
Most postman testing questions and rest api interview questions center on REST.
API Functional Testing Interview Questions & Answers (90+)
Section A: Fundamentals (Q1–Q20)
1. What is API functional testing?
Validating that an API performs expected business functions for given inputs.
2. How is functional API testing different from API testing?
Functional testing focuses on correctness of behavior and rules; API testing may also include performance/security.
3. What do you validate in functional API testing?
Status codes, response body, headers, schema, and business rules.
4. What is an endpoint?
A URL representing a resource/action, e.g., /orders/123.
5. What HTTP methods are used?
GET, POST, PUT, PATCH, DELETE.
6. PUT vs PATCH?
PUT replaces the full resource; PATCH updates part of it.
7. What is request payload?
Data sent to the server (JSON/XML).
8. What is response body?
Data returned by the server.
9. What is statelessness?
Each request contains all info needed to process it.
10. What is idempotency?
Same request repeated yields same result (e.g., PUT).
11. What is API versioning?
Managing changes via /v1, /v2.
12. What is authentication?
Proving identity (Bearer token, API key).
13. What is authorization?
Checking permissions for actions.
14. What is JWT?
A signed token carrying claims for auth.
15. What is API schema?
Definition of fields and data types.
16. What is API chaining?
Using one API’s response in another request.
17. What is negative testing?
Testing invalid inputs/flows.
18. What is boundary testing?
Testing min/max values.
19. What is regression testing?
Re-testing after changes.
20. What is smoke testing?
Basic health checks.
Section B: Status Codes & Validations (Q21–Q35)
| Code | Meaning | When Used |
| 200 | OK | Success |
| 201 | Created | Resource created |
| 204 | No Content | Success w/o body |
| 400 | Bad Request | Invalid input |
| 401 | Unauthorized | Invalid/expired 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 always correct?
No—data may still be wrong.
22. What else to validate besides status?
Response body, headers, schema, and rules.
23. What is content-type validation?
Ensuring JSON/XML is correct.
24. What is header validation?
Checking Authorization, Cache-Control, etc.
25. What is response time validation?
Ensuring SLA compliance.
26. What is schema validation?
Ensuring structure and types match spec.
27. What is business rule validation?
Checking domain logic (limits, totals).
28. What is pagination testing?
Validating page size and navigation.
29. What is filtering/sorting testing?
Ensuring query params work.
30. What is rate limiting?
Restricting request counts.
31. What is rollback?
Reverting partial failures.
32. What is data consistency?
Same data across systems.
33. What is concurrency testing?
Parallel requests correctness.
34. What is caching validation?
Ensuring cache behavior is correct.
35. What is monitoring?
Tracking availability/errors.
Section C: Functional Examples (Q36–Q55)
36. How do you test a Create (POST) API?
Validate 201, body fields, DB effect.
37. How do you test a Read (GET) API?
Validate 200, correct fields, filters.
38. How do you test Update (PUT/PATCH)?
Validate updated fields and unchanged fields.
39. How do you test Delete (DELETE)?
Validate 204 and resource removal.
40. How do you test validation rules?
Send invalid payloads and expect 400/422.
41. How do you test auth failures?
Invalid/missing token → 401/403.
42. How do you test idempotency?
Repeat PUT and compare results.
43. How do you test limits?
Exceed max/min values.
44. How do you test calculations?
Validate totals, tax, discounts.
45. How do you test date rules?
Past/future constraints.
46. How do you test file upload APIs?
Validate size/type rules.
47. How do you test webhooks?
Trigger events and verify callbacks.
48. How do you test dependencies?
Fail one service and verify handling.
49. How do you test localization?
Language/locale responses.
50. How do you test error messages?
Clear, actionable errors.
51. How do you test retries?
Simulate transient failures.
52. How do you test default values?
Omitted fields get defaults.
53. How do you test enums?
Reject unsupported values.
54. How do you test pagination edge cases?
Last page, empty page.
55. How do you test search APIs?
Exact vs partial matches.
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 and types match
Postman / SoapUI / RestAssured / Python Snippets
Postman Tests
pm.test(“201 Created”, () => {
pm.response.to.have.status(201);
});
pm.test(“Total calculation valid”, () => {
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)
- 200 OK but wrong total—what checks?
- Coupon applied twice—what validation missed?
- Order created without auth—what defect?
- PATCH updates all fields—issue?
- DELETE returns 200 with body—acceptable?
- Pagination returns duplicates—cause?
- Concurrent orders oversell stock—test?
- Expired token still works—defect?
- 422 vs 400—when to expect which?
- Different results for same query—why?
- Timezone causes date errors—test?
- Search ignores filters—where to look?
- Retry causes duplicates—how prevent?
- Webhook not fired—how verify?
- 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 Functional Testing Cheatsheet
- Validate business rules
- Test positive & negative paths
- Don’t trust 200 alone
- Check schema & headers
- Handle edge cases
- Use Postman scripts
FAQs – API Functional Testing Interview Questions
Q1. Is Postman enough for functional testing?
Yes, plus basic automation helps.
Q2. Do interviewers expect automation?
Nice to have; functional thinking matters most.
Q3. REST or SOAP?
REST is primary.
Q4. Biggest mistake?
Only checking status codes.Q5. How to prepare fast?
Practice scenarios with Postman.