# API testing checklist

QA Hub · Version 1 · 22 October 2026

Use this checklist for one endpoint at a time. Agree expected behavior with the API contract and product requirements; status codes and limits below are not universal defaults. Mark each check Pass / Fail / Not applicable and attach evidence. Run destructive scenarios only against disposable test data in an authorized test environment.

## Test record

- Endpoint and HTTP method:
- API version / build / environment:
- Contract or requirement:
- Test account and role:
- Prepared data and cleanup procedure:
- Expected status, response schema and business effect:
- Request/correlation ID, timestamp and evidence link:

## Contract and successful requests

- [ ] Minimum valid request succeeds and returns the documented status.
- [ ] A request with every supported field preserves its intended values.
- [ ] Response headers and media type match the contract.
- [ ] Required response fields exist; types, formats and nullability match the schema.
- [ ] IDs and relations refer to the expected records.
- [ ] Persistence matches the response; a follow-up read confirms the change.
- [ ] Read-only requests do not unexpectedly change business data.

## Input validation

- [ ] Required field omitted, explicitly null, empty, and whitespace-only are tested separately.
- [ ] Wrong type, malformed JSON and unsupported media type receive controlled errors.
- [ ] Boundary values are checked: minimum−1, minimum, maximum, maximum+1.
- [ ] Unicode, escaping, leading/trailing whitespace and long strings follow the contract.
- [ ] Unknown properties and unexpected enum values have explicit behavior.
- [ ] Nonexistent IDs and IDs belonging to another account are handled correctly.
- [ ] Invalid requests leave no partial records or unintended side effects.

## Identity and permissions

- [ ] Missing, expired and invalid credentials receive the expected response.
- [ ] Each relevant role can perform only its allowed operations.
- [ ] Account A cannot read or modify account B's object by changing its identifier.
- [ ] Unauthorized fields are neither returned nor writable.
- [ ] Errors and logs do not expose secrets, tokens or sensitive internal details.

## Lists, retries and state

- [ ] Empty results, one result and multiple pages behave consistently.
- [ ] Sorting has a deterministic tie-breaker where the contract requires stable order.
- [ ] Filters combine correctly; paging boundaries do not unexpectedly omit or repeat records.
- [ ] A repeated write behaves as documented; test idempotency keys if supported.
- [ ] Two competing updates follow the documented conflict policy.
- [ ] A cancelled/timed-out request is reconciled before retrying a potentially completed write.
- [ ] Documented rate limits and retry signals are checked at an agreed test rate.
- [ ] Dependency failures produce controlled responses and recover without data corruption.

## Completion

- [ ] Response-time targets were measured with documented workload and environment.
- [ ] Logs and correlation IDs allow the observed behavior to be investigated.
- [ ] Cleanup removed only the records created by this run.
- [ ] Defects include sanitized request, actual response, expected result and reproduction steps.

Example: for `POST /orders`, a rejected quantity must not create an order or reserve stock. Checking only the HTTP status would miss this failure.

Read next: https://qahub.pro/en/backend-api/negative-api-testing