Sending a request is only half the conversation. In Lesson 13.2 you assembled the envelope. Now the service answers — and its answer tells you whether it understood, what it did, and what to inspect next. Treat every response as evidence, not a black box.

The three parts of a response

Every response has the same three pieces, mirroring the request:

• Body — usually JSON: the data you asked for, or an error object explaining what went wrong. The fields are the payload; everything else is the verdict on the payload.
• Status code — a three-digit number summarizing the outcome: 200 for success, 404 for "not found," 500 for "our problem." Read this first.
• Headers — metadata about the reply: content type, rate-limit counters, caching hints, request IDs. You will mostly glance at these when debugging limits or reporting a problem.

A successful weather reply, trimmed, shows the pattern:

{
  "latitude": 50.85,
  "longitude": 4.35,
  "hourly": { "temperature_2m": [9.1, 9.4, 10.2] }
}

Status 200, body with exactly the fields requested, headers you can ignore for now. Compare that with a model reply from Lesson 13.5: status 200, body with choices plus a usage block. Same shape — data plus verdict.

Status codes: three families

You do not need to memorize dozens of codes. Learn the families, then the eight codes you will actually meet:

The eight to recognize on sight:

The 401 vs 403 split is worth memorizing now because Class 14 builds on it: 401 means "we don't know who you are," 403 means "we know who you are and the answer is no."

Errors are useful precisely because they carry this structure. A good error body names the problem:

{
  "error": {
    "code": "missing_field",
    "message": "items[0].sku is required",
    "doc": "https://docs.example-shop.com/v1/orders#fields"
  }
}

That is not an insult. It is the service pointing at the exact line of your envelope to fix.

The debugging order

When a call fails, work in this order — it resolves most failures in minutes:

1. Read the status → which family? whose problem?
2. Read the message → which field, endpoint, or credential?
3. Compare to docs → endpoint name, method, field spelling
4. Reduce → smallest request that still reproduces it

Concretely: a 400 sends you to your body fields. A 401 sends you to your Authorization header and .env loading. A 404 sends you to the URL — one character off in an endpoint or ID is the classic cause. A 429 sends you to the docs' rate-limit section, not to a faster retry loop. A 500 sends you to the provider's status page and a pause.

The "reduce" step is the professional habit: strip the request to one field, one item, one record. If the minimal version works, add pieces back until it breaks — you have found the culprit. If the minimal version fails, you have a clean example to paste into docs or a support request (with secrets redacted).

Agents must report, not silently retry

This matters doubly once an agent makes calls for you. Give your agent this rule now, before Class 15 hands it tools:

Reading is safe to retry: a failed GET can be re-sent. But a POST that creates an order, sends an email, or charges a card must not be hammered until something sticks — two "failed" retries can become three charges. The agent should show you the status, the message, and its proposed fix, then wait for approval on anything that writes, sends, or spends. You will formalize this as an approval gate in Class 14 and Part VII; start the habit here.

Practical exercise: diagnose six responses

For each of these, write: what succeeded or failed, what evidence you have, and the next safe action.

1. 200 + forecast JSON with the requested fields. 2. 201 + {"order_id": "ord_881"}. 3. 400 + {"message": "currency is required"}. 4. 401 + {"message": "invalid API key"}. 5. 404 + {"message": "no submission found for CIK…"}. 6. 429 + {"message": "rate limit exceeded, retry after 60s"}.

Finish line: six one-line diagnoses, each in the form evidence → verdict → next action (e.g. "status 401 + 'invalid key' → identity problem → re-check .env loading, do not retry blindly").

Verify: for #4 and #5, can you say why the fixes live in different places (headers vs URL)? If yes, you are reading responses, not just fearing them.

Common failure mode: retrying the identical request five times hoping the service changes its mind. Services are consistent; if you change nothing, the answer will not change — except to rate-limit you.

Check your understanding

1. What are the three parts of a response, and which do you read first? 2. What does each status family (2xx, 4xx, 5xx) tell you about whose side needs attention? 3. What is the difference between 401 and 403, in one sentence each? 4. What is the four-step debugging order, and why does "reduce" come last? 5. Why must an agent report a failed POST and propose a fix instead of silently retrying it?