How can an API response body differ from its HTTP status code?

They are separate parts of the response. The status code indicates the outcome; headers carry metadata; and the optional body can contain requested data or describe a problem. The body may therefore provide information that the status code alone does not express. [S1]

For example, an API might return a status indicating an unsuccessful outcome and a body explaining which input needs attention. That is an illustrative pattern, not a claim about any particular API. Check the API’s documentation to learn what its response fields mean.

Here is a hypothetical example. The status and body wording are placeholders; an API may use different values and formats.

Status: [response status code]
Content-Type: application/json

{
  "error": "invalid_input",
  "message": "Check the date field."
}

Read it in three parts:

1. [response status code] is the status. It communicates the response outcome.
2. Content-Type: application/json is a header, which provides metadata about the response.
3. The JSON object is the body. In this illustrative example, it gives a more specific problem description.

The status, header, and body are distinct parts of an HTTP response. [S1] The example does not establish that a real service uses this header or these particular fields for this situation.

If a body is present, inspect it when your task depends on the returned data or details. A status code and body have different roles, so one does not substitute for reading the other. The API’s documentation can tell you what a particular body means.

Also check whether a body is expected before trying to parse one. Some responses, including 204 No Content, have no body. [S1] The source does not specify how every programming language or API client handles a response with no content.

Note the status, relevant headers, and body as separate observations. For example:

Status: [status code and reason phrase, if shown]
Headers: [relevant response headers]
Body: [returned content, or “none observed”]

Then compare those observations with the API documentation. Do not assume the body’s wording is a universal explanation: services can define their own response formats. The available guidance establishes that bodies can contain data or problem descriptions and that headers provide context; it does not establish a particular API’s field names, error meanings, or client behavior. [S1]