Format an API Error Response
Structured error responses help API clients handle failures gracefully, but they often arrive minified and hard to read. This example follows the RFC 7807 Problem Details format used by many REST APIs. Formatting makes it immediately clear which field failed validation and why. Understanding the error structure helps you write better error-handling code on the client side.
Example
{
"type": "https://example.com/problems/validation-error",
"title": "Validation Failed",
"status": 422,
"detail": "One or more fields failed validation.",
"instance": "/api/users",
"errors": [
{ "field": "email", "message": "Must be a valid email address." },
{ "field": "password", "message": "Must be at least 8 characters." }
]
}FAQ
- What is RFC 7807?
- RFC 7807 defines a standard JSON format for HTTP API error responses, including type, title, status, detail, and instance fields that clients can programmatically handle.
- How should I handle 422 validation errors?
- A 422 Unprocessable Entity means the request syntax was valid but the data failed business validation. Read the errors array to know which fields to highlight in your UI.
- Should API errors always return JSON?
- Best practice is yes, especially for APIs consumed by code. Returning HTML error pages breaks client JSON parsers and makes error handling much harder.
Related Examples
Format a REST API Response
REST APIs return compact JSON that is hard to read at a glance. Paste this examp...
Format a Webhook PayloadWebhooks deliver events as JSON POST bodies that often arrive minified. This exa...
Format a GraphQL ResponseGraphQL responses always follow a predictable envelope with a data field and an ...