API Testing Checklist for QA Engineers — 30 Things to Cover

Published 2026-03-12 · 8 min read
A printable checklist organised by category. Use it for code review, for new-API onboarding, or as the spine of a regression suite.

1. Happy path

• Each endpoint returns the documented status code (200/201/204) on valid input
• Response body matches the OpenAPI schema exactly (no extra, no missing fields)
• Pagination returns page, limit, total, hasNext correctly
• Sorting / filtering parameters actually affect the result set
• Created resources are immediately readable via GET

2. Schema validation

• Required fields rejected with 400 when missing
• Wrong types (string for number) rejected with 400, not 500
• Unknown fields either rejected or silently dropped — pick one and enforce
• String length / number range constraints enforced
• Enum values outside the allowed set rejected

3. Authentication & authorization

• Missing token → 401 with WWW-Authenticate header
• Expired token → 401 (not 403)
• Valid token, wrong scope → 403 (not 401)
• Token from another tenant cannot access this tenant's data (BOLA / IDOR)
• Refresh-token rotation — old refresh token invalidated after use
• Practice on the free auth sandbox

4. Error handling

• Error responses follow a consistent envelope ({ error, message, code })
• 5xx responses don't leak stack traces in production
• Idempotent retries on 5xx don't double-create resources (use Idempotency-Key)
• Partial-failure responses (e.g. bulk insert) clearly state which items failed

5. Performance

• p95 latency under SLO for each endpoint at expected QPS
• Pagination doesn't degrade past page 100 (no offset-table-scans)
• Heavy filters use indexes — confirm with EXPLAIN, not vibes
• Concurrent writes don't deadlock or lose updates

6. Security

• SQL / NoSQL injection — fuzz every string field
• Command injection — anywhere the API spawns a process
• SSRF — anywhere the API fetches URLs the user controls
• Mass assignment — POST /users with { "isAdmin": true } shouldn't work
• Rate limiting actually enforced and headers (X-RateLimit-*) returned
• CORS allowlist tight — wildcard * only on truly public reads

7. Observability

• Every request has a correlation ID (X-Request-Id) in logs and response
• 4xx vs 5xx distinguishable in metrics
• Audit log for sensitive mutations (delete user, change role, refund)

How to practice

The TotalShiftLeft sandbox implements ?error=500, ?delay=2000 and ?random_fail=true on every endpoint — perfect for exercising sections 4 and 5 without breaking real services.

Tooling

• Postman / Newman — easiest start, integrates with CI
• RestAssured — JVM teams shipping Java/Kotlin
• Karate — BDD-style, works for both API and UI
• Schemathesis — property-based fuzzing from your OpenAPI spec
• k6 / Locust — load testing, sections 5

Frequently asked questions

Is this checklist enough for security sign-off?

No. It catches the obvious classes. Pair it with a focused pentest or DAST scan before launching anything that handles money or PII.

How long should this take per endpoint?

A trained engineer covers all 30 items in 30–45 minutes once tooling is in place. The first endpoint takes a day.

Other free public APIs in this sandbox

Topics: API testing checklist · QA API testing · API test cases · API testing best practices · API automation checklist