API Error Handling

Scope Boundaries

• Use when API error taxonomy, response schemas, and status mapping are being created or changed.
• Use proactively when failure handling is implicit, inconsistent, or incident learning needs to be codified in the contract.
• Use proactively when error payload or status-mapping diffs are detected without explicit retry/backoff policy.
• Use when retry/backoff behavior affects client correctness or operational stability.
• Do not use for transport-independent incident handling policy; use incident-postmortem or runbook skills.
• Do not use for storage internals; use db-*.

Goal

Deliver machine-actionable error contracts that are stable across versions.