This API testing checklist is the list to run through for every endpoint you test, whether manually in Postman or in an automated suite. It starts with the core per-endpoint checks, adds a catalogue of negative and edge cases, and ends with a senior-level checklist for reviewing an entire API test suite.
Checklist for Every Endpoint
| Category | Tests to Write |
|---|---|
| Happy Path | Valid input → correct 2xx, correct response body, schema matches |
| Auth | No token → 401; wrong role → 403; expired token → 401; valid → 200 |
| Validation | Missing required fields → 400/422; wrong types → 400/422; out of range → 422 |
| Not Found | Non-existent ID → 404 (never 500) |
| Duplicates | Duplicate unique field (email) → 409 Conflict |
| BOLA | Access another user's resource → 403 (not 200!) |
| Rate Limiting | Exceed limit → 429 with Retry-After header |
| Schema | Response structure matches JSON Schema |
| Response Time | Response < defined SLA (e.g., 2 seconds) |
| Error Format | All errors have consistent structure (code + message) |
| No Sensitive Data | Password, secrets, CVV never in response body |
| Idempotency | PUT/DELETE same request twice → same result |
"Always ask: What does success look like? What does failure look like?"
"Think in test categories: functional → security → performance → contract"
"Negative tests matter MORE than positive tests at senior level"
"Mention: schema validation, BOLA, rate limit, idempotency — these show depth"
"For every endpoint: draw the test matrix — who can do what, what inputs are valid"
Your RestAssured + Pact + security testing knowledge from this guide
puts you in the top 5% of API testing candidates. Now practise writing it. 🚀
Negative and Edge-Case Catalogue
| Category | Test Scenario | Expected Behaviour |
|---|---|---|
| Missing fields | POST /users without required "email" field | 400 or 422 with field-level error message |
| Wrong data type | POST /orders with "quantity": "two" (string not int) | 400 with type validation error |
| Out of range | POST /user with "age": -5 or age: 999 | 422 with range validation error |
| Invalid format | POST /users with "email": "not-an-email" | 422 with format validation error |
| Duplicate | POST /users with email that already exists | 409 Conflict |
| Wrong ID | GET /users/999999 (non-existent) | 404 Not Found |
| Empty body | POST /users with no body or empty {} | 400 Bad Request |
| Null values | PUT /users/42 with { "name": null } | 422 or 400 if name is required |
| Too long | POST /users with 10,000-char name | 422 or 400 field length violation |
| SQL injection | GET /users?name='; DROP TABLE users;-- | 400 or 200 with sanitised input (NOT 500) |
| XSS payload | POST /users with name: "<script>alert(1)</script>" | Stored sanitised or 400 rejected |
| Unauthorised | GET /admin/users with customer token | 403 Forbidden |
| No auth | GET /api/private without any token | 401 Unauthorized |
| Method not allowed | DELETE /api/products/1 (read-only endpoint) | 405 Method Not Allowed |
| Rate limit | POST /auth/login 10 times rapidly | 429 Too Many Requests + Retry-After header |
| Large payload | POST /orders with 1,000 items in array | 413 Payload Too Large or 400 |
| Concurrent updates | Two simultaneous PUT /orders/1 with different data | One succeeds, one gets 409 Conflict (optimistic lock) |
Status Codes to Expect
| 2xx Success | 3xx Redirect | 4xx Client Error | 5xx Server Error |
|---|---|---|---|
| 200 OK | 301 Moved Permanently | 400 Bad Request | 500 Internal Server Error |
| 201 Created | 302 Found (temp) | 401 Unauthorized | 502 Bad Gateway |
| 204 No Content | 304 Not Modified | 403 Forbidden | 503 Service Unavailable |
| 206 Partial | 307 Temp Redirect | 404 Not Found | 504 Gateway Timeout |
| 405 Method Not Allowed | |||
| 409 Conflict | |||
| 422 Unprocessable | |||
| 429 Too Many Requests |
Senior Review Checklist for an API Test Suite
| # | Skill / Topic | Can You Do It? |
|---|---|---|
| 1 | Write GET/POST/PUT/PATCH/DELETE tests with RestAssured | ☐ Ready |
| 2 | Implement RequestSpec/ResponseSpec and BaseTest pattern | ☐ Ready |
| 3 | Extract values with JsonPath (nested, list, conditional) | ☐ Ready |
| 4 | Validate JSON Schema with matchesJsonSchemaInClasspath() | ☐ Ready |
| 5 | Test OAuth2 password grant + cache tokens with TokenManager | ☐ Ready |
| 6 | Build RBAC test matrix with @DataProvider — all role/endpoint combos | ☐ Ready |
| 7 | Write 5+ negative test scenarios for any endpoint | ☐ Ready |
| 8 | Write Pact consumer test + provider verification | ☐ Ready |
| 9 | Test GraphQL queries AND check "errors" field (never trust HTTP 200) | ☐ Ready |
| 10 | Write BOLA test (user A accesses user B's resource → must get 403) | ☐ Ready |
| 11 | Test OWASP Top 10 — name all 10 risks from memory | ☐ Ready |
| 12 | Stub a payment API with WireMock (success + decline + timeout + fault) | ☐ Ready |
| 13 | Run Postman collection with Newman in a CI pipeline | ☐ Ready |
| 14 | Test file upload (multipart), wrong MIME, too-large file | ☐ Ready |
| 15 | Set up webhook receiver with WireMock, verify HMAC signature | ☐ Ready |
| 16 | Test idempotency — same key = same result, no duplicate resource | ☐ Ready |
| 17 | Test ETag caching — first request 200 with ETag, second request 304 | ☐ Ready |
| 18 | Test CORS preflight OPTIONS → correct Access-Control-Allow-* headers | ☐ Ready |
| 19 | Validate API responses against OpenAPI spec using swagger-request-validator | ☐ Ready |
| 20 | Write JDBC assertions to verify DB state after API call | ☐ Ready |
| 21 | Test Kafka event published after API call using Testcontainers + Awaitility | ☐ Ready |
| 22 | Write a BDD API test in Karate DSL (or Cucumber + RestAssured) | ☐ Ready |
| 23 | Attach AllureRestAssured filter and annotate tests with @Feature/@Story | ☐ Ready |
| 24 | Design a complete API test framework from scratch — explain layer by layer | ☐ Ready |
| 25 | Answer all 30 advanced interview Q&As from Section 12 without looking | ☐ Ready |
You now have the most complete API testing guide available for SDET interview preparation.
The 3 things that will get you hired at FAANG / top product companies:
1. Security mindset — BOLA, OWASP, RBAC matrix. Most candidates skip this entirely.
2. Contract testing (Pact) — shows you think at system architecture level.
3. Communication — explain your test design decisions clearly during the interview.
Practice exercise before every interview:
"Design API tests for a POST /payments endpoint."
Write: happy path → auth tests → RBAC matrix → negative → security → performance.
Time yourself. Full answer in under 4 minutes. That is the FAANG interview pace.
Go build something great, Naveed. The offer is closer than you think. 🚀
FAQs
What should be tested in an API?
Status codes, response body and schema, headers, data persistence, error handling for invalid input, authentication and authorisation, performance under load, and behaviour on retries and edge cases.
What are negative test cases in API testing?
Requests that should be rejected: missing or invalid fields, wrong data types, invalid IDs, missing or expired tokens, wrong HTTP methods and oversized payloads. Each should return the right 4xx code with a clear error, never a 500.
Is this checklist useful for manual API testing?
Yes. Use it in Postman when exploring an endpoint, then automate the checks that matter most in REST Assured or Newman.
