Problem Details for HTTP APIs

Problem Details for HTTP APIs, standardized as RFC 9457 (which obsoletes the original RFC 7807), defines a machine-readable format for returning error details from an HTTP API. A problem is delivered as application/problem+json with a compact, well-known set of members so that failures look the same no matter which endpoint or provider produced them. It answers a client’s core question on any error: what went wrong, and what do I do about it?

• application/problem+json - A registered media type that flags the body as a structured problem, not an ad-hoc error.
• Core members - type, title, status, detail, and instance describe the error class, a summary, the HTTP status, specifics, and the affected resource.
• Extension members - Domain-specific fields can ride alongside the standard ones without breaking existing consumers.
• Documented type URIs - The type member is a URI that can resolve to human-readable docs for that error.
• Broad framework support - Common web frameworks emit problem+json out of the box.

In practice this is the standard that makes error handling governable across an API estate. I can require it in OpenAPI response schemas, enforce it with Spectral linting, and give every consumer one parsing path for failures. That consistency matters most in the agentic turn, where automated clients need a reliable, structured signal to decide whether to retry, escalate, or surface a clear explanation. This entry is the current revision of the format first published as Problem Details for HTTP APIs under RFC 7807.