Error response format
An error response format is the consistent structure an API uses for failed requests: the HTTP status code plus a machine-readable body, typically carrying a stable error code, a human-readable message, and often a pointer to the offending field or a documentation link. A documented, uniform format lets clients branch on the error code programmatically rather than parsing prose.
For an agent, the error body is the entire feedback loop. A human debugging a 400 reads the message, checks a forum, and adjusts; an unattended agent can only act on structure the docs told it to expect. A documented error format tells the agent which failures mean fix-the-request, which mean re-authenticate, which mean back off, and which mean stop — the branching logic of every recovery path.
Stability matters as much as structure. Error codes that are enumerated in the reference and guaranteed stable become part of the API contract an agent can be built against; messages that change wording freely are safe only if the code alongside them does not.
HTTP has a standardized option here: RFC 9457, Problem Details for HTTP APIs, defines a common JSON error body (`application/problem+json`). Adopting it — or documenting an equivalent house format completely — gives agent frameworks a shape they already know how to handle.
Discry records whether the error format is documented as one of the execution-documentation facts on an API's profile ('Error format documented'), and separately assesses error-recovery guidance as a comprehension check — whether the docs describe failure modes and how to recover from them, as fetched from the public documentation surface.
What does an AI agent make of your API?
Find out in about a minute — no signup.
Discry your API — free