Working checklist
In practice
A checklist item catches a deleted record still appearing in search results.
What helps: The tester chooses checks based on endpoint risk and records the result.
What gets missed: The checklist is clicked through mechanically without considering data ownership.
How to use this checklist
Start with the endpoint’s purpose. What resource does it expose? Who can use it? What data does it accept? What data should it never reveal? Then pick the checklist items that match the risk.
Do not run every item blindly. A public read only endpoint does not need the same coverage as an endpoint that changes billing data.
What to save
- Situation: A billing endpoint accepts updates, so the tester chooses deeper authorization, validation, and cleanup checks than a public read-only endpoint needs.
- Evidence: The checklist depth matches endpoint risk and records what was intentionally skipped.
- Easy miss: Every endpoint receives the same shallow pass through the list.
If any term here feels fuzzy, start with API Testing for QA Testers before running the checklist at work.
Request basics
- Confirm the method is correct.
- Confirm the URL path and version are correct.
- Confirm required headers are present.
- Confirm content type is accepted and rejected correctly.
- Confirm query parameters are documented and validated.
GET checks
GET checks should confirm the right data is returned for the right user. Test existing records, unknown records, filtered results, sorted results, empty results, and permission boundaries.
For a GET user profile request, confirm User A cannot see User B’s private profile fields.
Better vs weaker evidence
GET profile returns the correct name but includes a private billing flag for another user role.
Stronger evidence
The tester checks record ownership, empty results, sorting, filtering, and safe fields.
Thin evidence
The response is accepted because the visible fields looked right.
POST checks
POST checks should confirm creation behavior. Test valid payloads, missing required fields, invalid types, duplicate submissions, and response body fields. If the API creates an order, confirm the order can be retrieved afterward and that totals match expected calculations.
In practice
A create order request succeeds twice when the user double-submits the same payload.
What helps: The tester checks valid creation, duplicate behavior, required fields, and the follow-up GET.
What gets missed: The test stops after the first created response.
PUT and PATCH checks
PUT and PATCH checks should confirm update rules. Test full replacement, partial update, unchanged fields, invalid fields, and permissions. Pay attention to fields users should not be able to change, such as account role or billing status.
Better vs weaker evidence
A profile update lets a normal user change an account role field that should be server controlled.
Stronger evidence
The tester checks allowed fields, forbidden fields, unchanged fields, and permissions.
Thin evidence
The update test uses only friendly fields and misses privilege changes.
DELETE checks
DELETE checks should confirm what deleted means. Some systems remove records. Some mark them inactive. Confirm deleted records are not still returned where they should be hidden. Confirm repeated delete requests behave in a predictable way.
What to save
- Situation: A deleted record disappears from the detail page but still appears in search.
- Evidence: The tester checks the delete response, follow-up GET, list view, and repeated delete behavior.
- Easy miss: Success is accepted from the DELETE response without checking downstream visibility.
Status code checks
Status codes should match behavior. Check success, created, bad request, unauthorized, forbidden, not found, conflict, and rate limit responses where relevant. The body should not contradict the code. For a quick sanity check, use the MDN HTTP status code reference instead of guessing from memory.
What to save
- Situation: POST /password-reset returns 200 OK with {"success": false, "error": "invalid_token"} in the body. The mobile app’s response handler only checks status codes and shows a password reset email sent success screen even on failure.
- Evidence: The tester confirms 4xx codes are returned for client errors so generic clients, mobile apps, integrations, and monitoring can handle them without parsing the body.
- Easy miss: The API uses 200 for everything and every client has to learn the custom error envelope, leading to false-success bugs in every integration.
Payload validation
Test required fields, optional fields, boundaries, invalid formats, special characters, empty strings, null values, arrays, nested objects, and fields the client should not send. Confirm errors identify the field without leaking internals.
Better vs weaker evidence
POST /comments accepts a body with a 50,000-character message field. The database column is varchar(2000), so the response is a 500 error with a stack trace exposing the SQL.
Stronger evidence
The tester checks length boundaries such as 1, max-1, max, max+1, and way-over-max and confirms the API returns a clean 400 with a readable error before the request reaches the database.
Thin evidence
The tester only sends a short valid message, the field has no documented length limit, and the 500 only surfaces when a real user pastes a long Slack thread into the form.
Authentication checks
Send requests with no token, expired token, malformed token, and valid token. Confirm failures are handled safely. Do not assume one successful login proves authentication coverage.
Better vs weaker evidence
An expired token still returns profile data because the endpoint only checks whether a token-shaped value exists.
Stronger evidence
The tester sends no token, malformed token, expired token, and valid token and records the expected response for each.
Thin evidence
Authentication is marked covered after one successful login request.
Authorization checks
Use at least two roles or two users. Confirm users cannot access another user’s data. Confirm lower permission roles cannot create, update, or delete restricted resources. This is exactly the kind of testing habit that lines up with the risk areas described in the OWASP API Security Top 10.
Practice lens
User A can request User B’s record by changing an ID in the URL.
Useful evidence: The tester checks both roles and records the blocked response.
Thin evidence: The check runs only as an admin and misses broken object-level access.
Error handling
Error responses should help the client recover. They should be consistent, readable, and safe. A useful validation error is good. A stack trace in the response is not.
In practice
A missing required field returns a stack trace with a database table name instead of a safe validation message.
What helps: The tester checks status code, field message, response consistency, and whether internals are exposed.
What gets missed: The error is accepted because it failed, even though it leaks implementation detail.
Pagination and filtering
Confirm page size rules, next page behavior, first and last page behavior, empty pages, filters, sorting, and duplicate handling. Pagination bugs can hide records, repeat records, or make reports inaccurate.
Better vs weaker evidence
A customer list skips records between page two and page three.
Stronger evidence
The tester compares totals, ordering, filters, and duplicate records.
Thin evidence
Only the first page is checked, so missing production records stay hidden.
Rate limits
If rate limiting exists, confirm the response code, retry guidance, and client behavior. If it does not exist for a sensitive endpoint, raise the risk for the team to discuss.
Practice lens
A password reset endpoint accepts hundreds of requests without retry guidance or throttling behavior.
Useful evidence: The tester checks response code, retry message, and product risk when repeated requests are allowed.
Thin evidence: Rate limits are skipped because the normal request works once.
Data cleanup
Plan cleanup before you create data. Test orders, users, files, and tokens can pollute shared environments. Good cleanup keeps later tests meaningful.
Practice lens
A tester creates 50 test orders during a checkout test session and forgets to delete them. The next morning, a teammate’s pagination test fails because the result set is now bigger than expected.
Useful evidence: The test suite either creates data inside a transaction that rolls back, or includes an explicit teardown step that deletes what it created.
Thin evidence: Every test run leaves orphan records, and three weeks later nobody can tell which of the 8,000 test orders are still needed.
Logging and traceability
When a request fails, testers need enough traceability to investigate. Check whether responses include request IDs or correlation IDs where appropriate. Use logs to connect a failed test with server behavior.
In practice
A failed order request has no request ID, so support cannot connect the API response to server logs.
What helps: The tester captures correlation IDs, timestamps, payload details, and environment notes.
What gets missed: The defect report includes only the endpoint name and leaves investigation to guesswork.
Pipeline failures and deployment checks connect directly to QA in DevOps.
Common mistakes
- Checking only happy path GET requests. GET checks are only one slice of REST behavior. Cover create, update, delete, validation, auth, and cleanup so the checklist reflects how users actually move data through the product.
- Forgetting authorization tests between users. Authorization defects are easy to miss when every request uses the same user. Switch users, roles, and owned records so one customer cannot read or change another customer’s data.
- Trusting old test data. Old test data creates false positives. Use known records or create fresh data during the test so the result can be repeated by another tester.
- Ignoring cleanup until the environment is messy. Messy environments slow everyone down. Plan cleanup before creating records, then verify deleted or archived data no longer appears where users should not see it.
- Missing pagination and filtering because the first page looked fine. The first page often looks fine while later pages skip, repeat, or reorder records. Test page boundaries, filters, sort order, and empty results before calling the endpoint covered.
Practice lens
A REST checklist review finds that the endpoint passed happy-path GET checks but never switched users or cleaned up created records.
Useful evidence: The checklist is rerun against authorization, data lifecycle, pagination, and error behavior.
Thin evidence: The first green response hides the risks the checklist was supposed to catch.
Practice exercise
Choose one sample endpoint. Write checks for valid create, missing required field, invalid type, get created record, update record, unauthorized request, forbidden user, delete record, and cleanup. Write a short note explaining which risks remain untested.
In practice
A tester runs one sample endpoint through create, invalid field, unauthorized request, forbidden user, update, delete, and cleanup checks.
What helps: The exercise ends with evidence for each request and a note naming untested risks.
What gets missed: The practice stops after a valid create request and leaves test data behind.
Turn the finished checklist into resume evidence with the examples in QA Tester Resume Examples.
Turn this checklist into proof with AT*SQA
This checklist is the day-to-day work behind the AT*SQA API Testing AT*SkillStack: three micro-credentials covering Introduction and Testing Planning and Design, REST API gRPC and graphQL, and Environments Tools and Future Proofing. Each is $49, open-notes, two attempts, valid a year. The REST API micro-credential in particular maps directly to what you just read.
AT*SQA’s AT*Learn API Testing training (a one-year subscription starting at $39) is an easy way to prep.
Earn all three and the full API Testing certification is yours at no additional cost, $147 total. Each micro-credential appears on the Official U.S. List of Certified and Credentialed Software Testers and adds Testing Tiers points, giving you three concrete API testing skills a hiring manager can verify.
FAQ
Questions testers ask
Should every API endpoint use the full checklist?
No. Match checklist depth to product risk. A billing endpoint deserves more coverage than a low risk public lookup.
What is the most missed REST API check?
Authorization between users is often missed because testers use one admin account and never switch roles.
How do I test pagination?
Create or find enough records to require multiple pages, then check page size, order, first page, last page, and duplicate or missing records.
Why does cleanup matter?
Leftover data can make later tests pass or fail for the wrong reason. Cleanup protects the environment and your results.
How do I decide which REST API checklist items matter for an endpoint?
Start with risk. Endpoints that change money, private data, permissions, or account state deserve deeper checks than public read-only endpoints. Use the checklist to choose coverage, not to create busywork.
How do I test REST API authorization between users?
Create or use two users with different data, then try to read or change User B’s records while authenticated as User A. Confirm the response is blocked and the data is not leaked. Repeat the check for read, update, delete, and list endpoints where relevant.
What should I check in a REST API error response?
Check the status code, error message, field-level detail, response consistency, and whether sensitive internals are exposed. A useful error helps legitimate clients fix the request. It should not reveal stack traces, tokens, queries, or private implementation details.
How do I test pagination without missing defects?
Create or find enough data to cross page boundaries, then check first page, middle page, last page, sorting, filters, and duplicate records. Pagination defects often hide as missing or repeated items. Compare totals when the API provides them.
How do I keep API test data from polluting shared environments?
Create data with recognizable names, clean it up after the test, and avoid relying on old shared records. When cleanup is not possible, document it and use isolated test accounts. Dirty data makes later failures harder to trust.