Problem

The Handling Errors page lists AxiosError properties (message, name, stack, config, code, status) but never shows the complete object structure in one place. This makes it hard for developers to understand what's available when debugging errors.

Specific gaps:

1. error.response is not documented as containing the full response schema. The error handling page shows error.response.data, error.response.status, etc. in the catch example, but never explains that error.response has the same structure as a successful response (as documented in Response Schema).

2. error.response.data — the most useful property for debugging — is barely mentioned. There's no example of what it actually contains (the server's error response body).

3. No complete example of the AxiosError object. A simple visual like this would save developers a lot of confusion:

// When server responds with non-2xx status:
error = {
  message: "Request failed with status code 400",  // generic, generated by axios
  name: "AxiosError",
  code: "ERR_BAD_REQUEST",
  status: 400,
  config: { /* request config */ },
  request: { /* outgoing request */ },
  response: {                          // ← same structure as successful response
    status: 400,
    statusText: "Bad Request",
    headers: { /* response headers */ },
    data: { /* the actual error body from the server */ },
    config: { /* request config */ },
    request: { /* outgoing request */ },
  },
}

4. The Response Schema page only documents the success case, with no mention that the same structure appears inside error.response.

Suggested fix

Add a complete AxiosError object example to the error handling page that shows the nested response object, so developers can see at a glance where the server's actual error data lives (error.response.data).