What to record when an API returns the right status with the wrong body

When an API returns the expected status code but the wrong body, record the request, response status, response body shape, missing or unexpected fields, and the contract you used for comparison.

A 200 response can still be a bug. The endpoint may return an empty array when a record exists, omit a field that the UI depends on, return a string where a number was expected, or include stale data after a write. If the report only says “API is broken,” the reader has to guess whether transport, auth, filtering, serialization, cache, or data shape is involved.

Start with the safe request summary: method, route pattern, query parameters without secrets, body shape, and account state if relevant. Then show the status code and a reduced response body. Keep only the fields that prove the mismatch. If the response is large, do not paste everything. Show the path to the wrong field and the observed value. Then write the expected field, count, type, or ordering rule.

Also record whether the same request changes after refresh, time delay, different filter, or different user role. A right status with a wrong body is often a contract or freshness problem, not a network failure.

The practical rule is to debug the body as data, not as a successful request. Status code says the request completed; it does not prove the result matched the use case.

What to record when an API returns the right status with the wrong body

// COMMENTS

ON THIS PAGE