Compose a spec-compliant application/problem+json error payload — the five standard members (type, title, status, detail, instance) plus the errors array from RFC 9457 and custom extension members. Linter flags missing required fields, status/title drift, and non-URI type values. Copy the JSON, a complete HTTP response, or a ready-to-paste curl reproduction.
RFC 7807 (and its 2023 update RFC 9457) standardizes how HTTP APIs describe errors. Instead of every service inventing its own envelope, a problem response carries five well-known members: type (a URI that identifies the problem class — dereference-able is nice but not required; the placeholder about:blank means "no documentation"), title (a short human-readable summary; should not vary between occurrences of the same type), status (advisory — must match the actual HTTP status code), detail (a human-readable explanation specific to this occurrence — safe to include user-controlled input only after escaping), and instance (a URI identifying this occurrence — usually a request ID or resource path). RFC 9457 §3.1.4 adds the optional errors array for per-field validation problems ({ detail, pointer, name }). Servers may add extension members at the top level (e.g. balance, accounts); clients MUST ignore members they don't recognize. The response MIME type is application/problem+json (or application/problem+xml), distinct from application/json so a generic JSON parser can still consume it but content negotiation can prefer problem-aware handling. The body is permitted on any 4xx or 5xx response and is used by Spring 6's ProblemDetail, ASP.NET Core's ProblemDetails, and most modern API gateways.