RFC 9457: Structured Errors Cut AI Agent Costs 98%

If you are still returning {"error": "Something went wrong"} from your HTTP APIs in 2026, it is time to upgrade. RFC 9457 (Problem Details for HTTP APIs) is now the de facto standard — and it obsoletes the older RFC 7807 that most teams copy-pasted into production years ago.

Here is what actually changed and what it means for your services.

What RFC 9457 defines

A standard JSON (or XML) shape for error responses so clients can reliably parse and act on failures:

{
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "status": 403,
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/msgs/abc",
  "balance": 30,
  "accounts": ["/account/12345", "/account/67890"]
}

The required fields are minimal: type, title, status, detail, and instance. Everything else is an extension you control.

What is new vs RFC 7807

Clarifications around extension members — you can safely add your own fields without breaking clients
Better guidance on type URIs — they should be stable and dereferenceable documentation
Explicit support for i18n via content negotiation
Tightened security guidance so you do not leak stack traces or internal IDs

Why this matters for your team

Clients can finally handle errors generically. No more "every service has its own error shape."
Observability gets easier. Your logs and traces can pivot on type without custom parsers per service.
Fewer support tickets. A stable instance URL makes bug reports actually reproducible.