# RFC 7807 standardizes HTTP API error response details

DevFeed: [RFC 7807 standardizes HTTP API error response details](<https://devfeed.tech/articles/how-do-you-know-what-s-gone-wrong-when-your-api-request-fails-19069.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/http-api-problem-details/>)

Author: HTTP Toolkit; Tim Perry

Published: 2020-11-24T13:35:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [client](<https://devfeed.tech/topics/client.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [apis](<https://devfeed.tech/tags/apis.md>), [error-handling](<https://devfeed.tech/tags/error-handling.md>), [errors](<https://devfeed.tech/tags/errors.md>), [http](<https://devfeed.tech/tags/http.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [responses](<https://devfeed.tech/tags/responses.md>), [standard](<https://devfeed.tech/tags/standard.md>), [standards](<https://devfeed.tech/tags/standards.md>)

## AI overview

The article explains that HTTP status codes often do not provide enough detail to diagnose API failures. It presents RFC 7807 from the IETF as a proposed standard format for HTTP API error responses, with consistent error identifiers, descriptions, and metadata.

## Source excerpt

When an API request doesn't work, hopefully the client receives a sensible HTTP error status, like 409 or 500, which is a good start. Unfortunately though, whilst 400 Bad Request might be enough to know who's at fault, it's rarely enough information to understand or fix the actual problem. Many APIs will give you more details in the response body, but sadly each with their own custom style, varying between APIs or even between individual endpoints, requiring custom logic or human intervention to understand. This is not inevitable. Suspend disbelief with me for a second. Imagine a better world, where instead every API returns errors in the same standard format. We could have consistent identifiers to recognize types of errors, and clear descriptions and metadata easily available, everywhere. Your generic HTTP client could provide fine-grained details for any error automatically, your client error handling could easily & reliably differentiate specific errors you care about, and you could handle common errors across many different APIs with one set of shared logic. RFC 7807 from the IETF is a proposed standard aiming to do exactly this, by defining a standard format for HTTP API error responses. It's seeing real-world usage already, it's easy to start supporting in existing APIs and clients, and it's well worth a look for everybody who builds or consumes HTTP APIs. Why is a standard error format useful? (Please don't do this) Let's step back a little. One key feature of HTTP is the use of standard response status codes, like 200 or 404. When used correctly, these ensure that clients can automatically understand the overall status of a response, and take appropriate action based on that. Status codes are especially great for error handling. Rather than requiring custom rules to parse & interpret every response everywhere, almost all standard HTTP clients will throw an error automatically for you when a request receives an unexpected 500 status, and this ensures that un