Does a 200 Status Code Mean the User's Action Succeeded?
HTTP status and application outcome are related, not interchangeable.
Precise claimHTTP 200 and response.ok describe an HTTP-layer result; the detailed application outcome also depends on the method-specific content and the API's declared response contract.
Applies
A synthetic POST /orders fixture with a fixed HTTP 200 envelope and an explicit two-state JSON contract interpreted entirely in the browser.
Does not prove
The page does not recommend always returning 200, claim status codes are irrelevant, or infer how an undocumented real API should encode domain failures.
Portable rule
If a workflow conclusion comes from an HTTP response, then check both protocol status and the documented response contract before asserting the business outcome.
Contract-aware product stateOrder not createdOUT_OF_STOCK
HTTP 200 and response.ok describe an HTTP-layer result; the detailed application outcome also depends on the method-specific content and the API's declared response contract.
200 still has HTTP meaning. The narrower correction is that a status-only view cannot establish the detailed result carried by the response content and its declared contract.
The rebuilt model
You assumed:
If monitoring reports HTTP 200 or Fetch exposes response.ok as true, the user's requested business action must have completed.
The actual model:
A response has multiple semantic layers. Status summarizes the HTTP result; content represents the method-specific result; a documented schema tells a particular client how to turn that representation into product state.
The variable that failed you:
Response content — the status-only monitor omitted the object that the declared application contract uses to decide whether an order exists.
Change one variable
Freeze the envelope. Change only the JSON.
POST /orders200 OKresponse.ok = true184 msChanged: response body
Reference mode opens the interpreter without manufacturing a prediction.
Defines status-associated API responses and their content schemas as part of an operation contract.
standard — checked 2026-07-21.
Scope: A synthetic POST /orders fixture with a fixed HTTP 200 envelope and an explicit two-state JSON contract interpreted entirely in the browser.
Does not prove: The page does not recommend always returning 200, claim status codes are irrelevant, or infer how an undocumented real API should encode domain failures.
If a workflow conclusion comes from an HTTP response, then check both protocol status and the documented response contract before asserting the business outcome.
Frontend review
After checking response.ok, validate the expected success or error shape before showing a confirmation state.
Synthetic monitoring
Pair status assertions with a stable content or state assertion when the real requirement is a completed workflow.
API design
Document which outcomes live in status, body schema and asynchronous state instead of making clients infer the boundary.