Skip to main content

The error envelope

Errors do not reuse the success envelope. They carry an extra status field and nest the message one level deeper:
Read the message from data.message. Read the status from the HTTP status line — the statusCode field mirrors it and is there for clients that lose the status line through a proxy.
One exception worth knowing before you write a parser: a request that never reaches a mounted route is answered by the framework’s not-found handler, which returns {"statusCode":404,"status":"failed","data":{"message":"Cannot GET /the/path"}}. If you see that Cannot <METHOD> <path> string, the route does not exist on that host — it is not an auth or permission failure. A route that exists but rejects you returns 401, not 404, except where noted below.

HTTP status usage

Codes you will hit

These are stable, machine-readable strings. Match on the code, never on the message text.

Checkout and PSP readiness

Returned by GET /checkout/:shopUrl/payment-intent-resolver, inside data.meta.breakerSkipped[], to explain why a payment method the shop nominally has is not being offered: A live response for a shop in that state:
Resolve payment availability at request time from this endpoint. A shop’s configured method list is not the same thing as a method that can take money right now.

x402 settlement

Agent surfaces

Throttling

What to do with an unknown code

Codes are added as subsystems learn to explain themselves. Treat an unrecognised reason/code as a hard failure for that path — do not fall through to a different payment method on your side. If a code you are seeing is not listed here, tell us: an uncatalogued code is a documentation bug.