Error codes and types are documented

When an API returns a 401, 422, or 429 and the docs say nothing about error responses, developers have no way to write correct error handling — they cargo-cult whatever they saw in a Stack Overflow answer. Libraries that throw custom error classes but never document them force consumers to catch generic Error and inspect message strings, a fragile pattern that breaks across versions. Every undocumented error is a latent incident: the integrator doesn't know the error is possible, doesn't handle it, and a user sees an unhandled exception. iso-25010:2011 analysability covers this: a system where all failure modes are documented is fundamentally more maintainable than one where they are discovered at runtime.

Add an Errors section to your API reference with every status code, its cause, and how to resolve it:

## Errors

| Status | Code | Cause | Resolution |
|--------|------|-------|------------|
| 400 | invalid_request | Body failed validation | Check required fields and types |
| 401 | unauthorized | API key missing or invalid | Verify your API key |
| 404 | not_found | Resource does not exist | Check the resource ID |
| 429 | rate_limited | Too many requests | Retry after the Retry-After header value |
| 500 | internal_error | Server error | Contact support with the request ID |

For libraries, document every custom error class with the conditions that trigger it. Enumerate the complete error set — partial error docs give a false sense of completeness.