HTTP status evidence

HTTP status evidence is the set of request and response details needed to interpret an API failure beyond the numeric status code. The status code names a class of result, but the debugging value usually comes from method, URL path, request body shape, response body, request id, auth state, retry timing, client runtime, and cache or proxy information.

MDN documents the broad families of HTTP response status codes and the browser Response.status property. That gives a shared vocabulary, but a 400, 401, 403, 404, 409, 422, 429, or 500 can each have different causes depending on the endpoint contract and deployment path. A 409 may mean duplicate state, a 429 may mean quota or rate policy, and a 500 may still need a request id before a server-side trace can be found.

A good API note includes the smallest request that reproduces the issue, redacted headers, payload fields, exact status, response body, timestamp, user or tenant scope if relevant, retry result, and whether the same request works from another client. It should also mark whether the error is deterministic or intermittent.

The goal is not to paste a large raw trace. The goal is to preserve enough structured evidence that the next person can separate client misuse, permission state, validation failure, quota behavior, network layer issues, and backend defects.

Http status evidence method url body retry 2026 06 26

// COMMENTS

ON THIS PAGE

Http status evidence method url body retry 2026 06 26

// COMMENTS ↓ Newest First

ON THIS PAGE

// COMMENTS