api-testinglisted

# API Testing ## Why test at the API layer Faster, more deterministic, and catches issues the UI might mask (a UI can silently swallow a 500 and show stale cached data). Always cross-check UI-observed bugs against the raw API response before filing — it tells you whether the bug is frontend or backend. ## Core checklist per endpoint - **Status codes**: correct code for success (200/201/204), client error (400/401/403/404/409/422), server error (500). A 200 with an error body in it is a common anti-pattern to flag. - **Response schema**: matches documented/expected shape — types, required fields present, no leaked internal fields (password hashes, internal IDs meant to be opaque). - **Request validation**: missing required fields, wrong types, extra unexpected fields, malformed JSON — server should reject cleanly, not 500. - **Auth**: no token → 401; wrong-role token → 403; expired token → 401 with clear error, not a silent empty response; token for another tenant/user → must not leak cross-tenant data (test this explicitly, it's a common critical bug). - **Pagination**: first page, last page, page beyond range, page size 0/negative/huge, consistent ordering across pages (no duplicate/skipped records from concurrent writes). - **Idempotency**: does retrying a POST (e.g. payment, order-create) create duplicates? Idempotency-key support if documented. - **Rate limiting**: does exceeding the limit return 429 with a sane `Retry-After`, or does it just fail unpredictably? - **Err