Error Response
The predictable JSON an API returns on failure, with a status, stable code, human message, and useful details.
See it
What it is
An error response pairs a non-success HTTP status with a predictable body explaining what went wrong. A useful shape has a stable machine-readable code, a human message, optional field-level details, and a request ID for support. The status says the broad category, such as 404 or 422; the code says the specific condition your client can handle, such as email_already_registered. Stripe's error object is the shape most developers have already met: a type, a code such as card_declined, a human message, and the param that failed.
RFC 9457 standardizes this idea as Problem Details for HTTP APIs, using application/problem+json and fields such as type, title, status, detail, and instance. Use it when clients need one consistent failure contract across endpoints. Add extension fields for domain codes and validation issues instead of inventing a different body for every route.
The trap is making clients parse prose. Messages change, get translated, and are written for people; branch on the stable code instead. Never send stack traces, SQL errors, secrets, or internal service names to the caller, and make sure failures produced by authentication and routing use the same public shape as failures from business logic.
Ask AI for it
Standardize every API failure as RFC 9457 Problem Details with the Content-Type application/problem+json. Return type, title, status, detail, and instance, plus a stable code, requestId, and an errors array for field validation. Map known domain failures to explicit HTTP status codes, handle unmatched routes and authentication failures through the same serializer, and log the full internal error server-side without exposing stack traces or database details in the response.