API Test Case Library
Five CSV packs of reusable API test cases: login, pagination, search and filtering, auth (API key, JWT, OAuth 2.0) and error handling
What's inside:
For: QA engineers, developers, test leads
Get your free copy
Enter your email and we'll send the download link to your inbox.
Preview: API Test Case Library
This page shows roughly the first 20% of the pack so you can judge it before you download. The full ZIP contains 7 files: login-test-cases.csv, pagination-test-cases.csv, search-filter-test-cases.csv, auth-test-cases.csv, error-handling-test-cases.csv, api-test-case-library-guide.pdf, api-test-case-library-guide.md.
How to use this library
Each CSV file is one area of API behaviour that nearly every service has. Every row is a test case with preconditions, the request, the expected result, a type and a priority. Copy the rows into your test-management tool, a spreadsheet, or your automation framework, and replace the placeholders in {braces} with your own paths, users and data.
The cases are written against common REST conventions and public standards (HTTP semantics in RFC 9110, OAuth 2.0 in RFC 6749 and RFC 7636 for PKCE, JWT in RFC 7519, problem details in RFC 9457). Where an API is allowed to choose, for example 400 or 422 for a validation error, the expected result says "as documented". Decide the rule once, write it in your OpenAPI description, and assert it everywhere.
- Start with the P1 cases. They are the ones that block a release when they fail.
- Assert the response body and headers, not only the status code. Many of these cases only fail on the body.
- Run the Security-type cases with two test users (and two tenants if you are multi-tenant). Authorization bugs only show up across users.
Columns
| Column | What goes in it |
|---|---|
| ID | Stable identifier. Keep it when you copy the case into your own tool so results stay traceable. |
| Title | What the case proves, written as a behaviour. |
| Preconditions | State that must exist before the request: users, tokens, seed data, configuration. |
| Input / Request | Method, path and the parts of the request that matter. Placeholders are in {braces}. |
| Expected Result | Status code plus the response properties to assert. Assert the body, not only the status. |
| Type | Positive, Negative, Boundary or Security. |
| Priority | P1, P2 or P3 (see the priority note). |
Priority: P1 = blocks release if failing; P2 = fix before the next release; P3 = good hygiene, schedule it. Type: Positive (happy path), Negative (must be rejected), Boundary (edge of a valid range), Security (abuse or authorization case).
Login and session
login-test-cases.csv · showing 6 of 30 rows. Credential checks, enumeration, lockout, MFA, session handling, refresh and reset.
LOGIN-001
Valid credentials return a session or token
- Preconditions
- Active user {user} with known password
- Input / Request
- POST /auth/login {"username":"{user}","password":"{password}"}
- Expected Result
- 200; body contains access token (or Set-Cookie session); token type and expiry present; no password echoed in the response
- Type
- Positive
- Priority
- P1
LOGIN-002
Username lookup is case-insensitive where the spec says so
- Preconditions
- Active user stored as user@example.com
- Input / Request
- POST /auth/login with username USER@EXAMPLE.COM
- Expected Result
- Matches the documented rule: 200 if usernames are case-insensitive, 401 if not. Behaviour is consistent with registration
- Type
- Boundary
- Priority
- P3
LOGIN-003
Wrong password is rejected
- Preconditions
- Active user {user}
- Input / Request
- POST /auth/login with wrong password
- Expected Result
- 401; generic error message; no token; no Set-Cookie
- Type
- Negative
- Priority
- P1
LOGIN-004
Unknown user gets the same error as wrong password
- Preconditions
- No user named ghost@example.com
- Input / Request
- POST /auth/login {"username":"ghost@example.com","password":"x"}
- Expected Result
- 401 with the same body, error code and similar latency as a wrong-password attempt (no user enumeration)
- Type
- Security
- Priority
- P1
LOGIN-005
Missing username field
- Preconditions
- -
- Input / Request
- POST /auth/login {"password":"{password}"}
- Expected Result
- 400 (or 422); error names the missing field; no stack trace
- Type
- Negative
- Priority
- P2
LOGIN-006
Missing password field
- Preconditions
- -
- Input / Request
- POST /auth/login {"username":"{user}"}
- Expected Result
- 400 (or 422); error names the missing field
- Type
- Negative
- Priority
- P2
Pagination
pagination-test-cases.csv · showing 6 of 28 rows. Page/size, offset/limit and cursor pagination, including caps and consistency.
PAGE-001
First page returns the default page size
- Preconditions
- Collection with more items than the default page size
- Input / Request
- GET /items
- Expected Result
- 200; item count equals the documented default; pagination metadata (next link, cursor or total) present
- Type
- Positive
- Priority
- P1
PAGE-002
Explicit page and size parameters
- Preconditions
- >= 25 items
- Input / Request
- GET /items?page=2&size=10
- Expected Result
- 200; 10 items; items 11-20 in the documented sort order
- Type
- Positive
- Priority
- P1
PAGE-003
Walking every page returns every item exactly once
- Preconditions
- Known item count N; data not changing during the test
- Input / Request
- Follow next links or cursors until the last page
- Expected Result
- Union of pages has N items; no duplicates; no gaps
- Type
- Positive
- Priority
- P1
PAGE-004
Last page is partial and signals the end
- Preconditions
- N items where N is not a multiple of size
- Input / Request
- GET the last page
- Expected Result
- Remaining N mod size items; next link absent or cursor null; hasMore=false
- Type
- Boundary
- Priority
- P1
PAGE-005
Page beyond the last page
- Preconditions
- N items
- Input / Request
- GET /items?page={last+1}
- Expected Result
- 200 with an empty list (or the documented 404); never a 500
- Type
- Boundary
- Priority
- P2
PAGE-006
Page number zero
- Preconditions
- -
- Input / Request
- GET /items?page=0
- Expected Result
- Documented behaviour: 400, or treated as the first page if pages are zero-based
- Type
- Boundary
- Priority
- P2
Search, filter and sort
search-filter-test-cases.csv · showing 6 of 30 rows. Filters, ranges, free-text search, sorting and field selection.
SRCH-001
Exact-match filter
- Preconditions
- Items with status open and closed
- Input / Request
- GET /orders?status=open
- Expected Result
- 200; every item has status=open; at least one item
- Type
- Positive
- Priority
- P1
SRCH-002
Filter with no matches
- Preconditions
- -
- Input / Request
- GET /orders?status=archived (no such items)
- Expected Result
- 200; empty list; not 404
- Type
- Boundary
- Priority
- P2
SRCH-003
Unknown enum value in filter
- Preconditions
- -
- Input / Request
- GET /orders?status=bogus
- Expected Result
- 400 naming the allowed values, or empty list if documented
- Type
- Negative
- Priority
- P2
SRCH-004
Multiple filters combine with AND
- Preconditions
- Mixed data
- Input / Request
- GET /orders?status=open¤cy=EUR
- Expected Result
- Every item matches both conditions
- Type
- Positive
- Priority
- P1
SRCH-005
Multi-value filter (OR within a field)
- Preconditions
- API supports status=open,pending or repeated keys
- Input / Request
- GET /orders?status=open,pending
- Expected Result
- Items with either status and no others
- Type
- Positive
- Priority
- P2
SRCH-006
Date range filter inclusive bounds
- Preconditions
- Orders on 2026-01-01 and 2026-01-31
- Input / Request
- GET /orders?from=2026-01-01&to=2026-01-31
- Expected Result
- Both boundary dates included or excluded exactly as documented
- Type
- Boundary
- Priority
- P1
Authentication and authorization
auth-test-cases.csv · showing 8 of 39 rows. API keys, JWT validation, OAuth 2.0 grants with PKCE, and object/function-level authorization.
AUTH-001
Valid API key is accepted
- Preconditions
- Active API key K
- Input / Request
- GET /resource with header X-API-Key: K
- Expected Result
- 200
- Type
- Positive
- Priority
- P1
AUTH-002
Missing API key
- Preconditions
- -
- Input / Request
- GET /resource without the header
- Expected Result
- 401; WWW-Authenticate or error body says a key is required
- Type
- Negative
- Priority
- P1
AUTH-003
Revoked API key
- Preconditions
- Key K revoked
- Input / Request
- GET /resource with K
- Expected Result
- 401; revocation takes effect within the documented time
- Type
- Security
- Priority
- P1
AUTH-004
API key sent in the query string is refused
- Preconditions
- -
- Input / Request
- GET /resource?api_key=K
- Expected Result
- 401 or 400 if the API requires header transport; keys in URLs end up in logs
- Type
- Security
- Priority
- P2
AUTH-005
Key scoped to read-only cannot write
- Preconditions
- Read-only key
- Input / Request
- POST /resource with that key
- Expected Result
- 403
- Type
- Security
- Priority
- P1
AUTH-006
Key from another environment
- Preconditions
- Key issued in staging
- Input / Request
- Call production-like test environment with it
- Expected Result
- 401
- Type
- Negative
- Priority
- P2
AUTH-007
Valid JWT is accepted
- Preconditions
- Token signed by the trusted issuer, not expired, correct audience
- Input / Request
- GET /resource Authorization: Bearer {jwt}
- Expected Result
- 200
- Type
- Positive
- Priority
- P1
AUTH-008
Expired JWT
- Preconditions
- Token with exp in the past
- Input / Request
- GET /resource with it
- Expected Result
- 401; error code indicates expiry
- Type
- Negative
- Priority
- P1
Error handling and validation
error-handling-test-cases.csv · showing 7 of 32 rows. Input validation, boundaries, HTTP error semantics, idempotency and safe error bodies.
ERR-001
Missing required body field
- Preconditions
- POST /customers requires email
- Input / Request
- POST /customers {"name":"Ada"}
- Expected Result
- 400 or 422; error identifies email; machine-readable code
- Type
- Negative
- Priority
- P1
ERR-002
Wrong data type
- Preconditions
- -
- Input / Request
- POST /customers {"email":"a@b.c","age":"forty"}
- Expected Result
- 400 or 422 naming age and the expected type
- Type
- Negative
- Priority
- P1
ERR-003
Null for a non-nullable field
- Preconditions
- -
- Input / Request
- POST /customers {"email":null}
- Expected Result
- 400 or 422
- Type
- Negative
- Priority
- P2
ERR-004
Invalid format (email)
- Preconditions
- -
- Input / Request
- POST /customers {"email":"not-an-email"}
- Expected Result
- 400 or 422 naming email
- Type
- Negative
- Priority
- P2
ERR-005
String at maximum length
- Preconditions
- name maxLength 100
- Input / Request
- name of exactly 100 characters
- Expected Result
- 201
- Type
- Boundary
- Priority
- P2
ERR-006
String one over maximum length
- Preconditions
- name maxLength 100
- Input / Request
- name of 101 characters
- Expected Result
- 400 or 422
- Type
- Boundary
- Priority
- P2
ERR-007
Number at minimum and maximum
- Preconditions
- quantity minimum 1, maximum 999
- Input / Request
- quantity 1 and quantity 999
- Expected Result
- 201 for both
- Type
- Boundary
- Priority
- P2
The rest of the pack
159 rows across 5 CSV files, and all 7 sections of the guide as PDF and Markdown. Enter your work email above and we will send the download link.
Want to automate your API testing?
Generate tests from OpenAPI specs, run in CI/CD, and scale quality across teams.