A 201 response proves nothing: twenty API checks that catch real bugs

The base request creates an order with the required fields and a valid token: product, quantity, delivery address. The server replies 201 Created, a Location header pointing at the created resource, and a body with the identifier, items, status and total.

Under RFC 9110 the 201 status means the request succeeded and resulted in a new resource. The scenario then unfolds: after the POST the order is fetched with GET and compared, changed with PATCH, read again, deleted and checked for absence.

One rule applies before every test: record three things — the original request, the expected response and the state of the system after the operation.

The first group answers whether the operation worked correctly, not merely whether a response arrived.

• Status code: matches the documentation and does not hide an error inside the body.
• Response structure: every required field present, nothing unexpected.
• Types and formats: identifier, quantity and creation date match the schema.
• Data values: what came back is what was sent — product, quantity, address.
• Business logic: the total follows the formula from the requirements rather than echoing the request; the status has a valid initial value; discount, delivery, taxes and rounding are applied in the right order.

Next the same request is altered one condition at a time. Remove the address and the product together and it is unclear what the server actually rejected.

The checks cover required fields, empty and null values, wrong types and formats, boundary and invalid values, and unknown or extra fields. For negative cases a 4xx code is not enough: the response must explain the reason, point at the specific field, and still not expose internal detail such as a stack trace, an SQL query or a path on disk.

The interesting part starts where a single response ends. The guide checks requests without valid authentication, access to other users' objects, and separation by role and function.

Then it looks at the system as a whole: object state after the operation, related business rules and side effects, repeat requests and idempotency, consistency across related endpoints. The example given: after ordering two units the stock should fall by two, after cancellation it should recover, and the linked payment or warehouse operation should move to the right state.

A separate requirement concerns contract hygiene: the response must not contain password hashes, internal identifiers or other people's email addresses. OWASP recommends limiting responses to the minimum necessary set of fields.

The list does not end at twenty; the set is chosen by contract and architecture: pagination, sorting and filtering, rate limiting, versioning and backward compatibility, concurrent updates and optimistic locking, timeouts and degradation of external dependencies, feature flags, asynchronous operations returning 202 Accepted, webhooks with signatures and retries, caching with ETag and 304 responses.

Manual checking is right while the expected result is still being clarified. Once a scenario is stable it moves into a collection: base URL and token go into the environment, the order identifier is saved into a collection variable after creation, later requests use it, and the assertions live in the post-response scripts.

The Collection Runner executes the chain end to end, and the same collection runs on a schedule or in CI/CD. Only stable checks are worth automating: while the expected result still moves, the test will break more often than it finds bugs.

Twenty checks are not a ritual but a way to separate "a response arrived" from "the system did the right thing". Half the list examines consequences rather than the response, and that is where the expensive bugs usually live.