Skip to main content
Error format The Payments API answers a failed request with one of three bodies. Which body you get depends on where the service catches the failure, not on which endpoint you called. A failure that the request pipeline catches before the API layer sees it answers a flat JSON body on application/json. The pipeline authenticates the caller (PBP-0003 at 401) and authorizes the action (PBP-0004 at 403). It also opens the tenant’s storage (PBP-0008 at 503) and runs the idempotency check. Everything the API layer catches answers an RFC 9457 problem document on the application/problem+json media type. The service-wide rate limiter answers 429 with the plain text Too Many Requests and no error code.
Field definitions
  • type – A URI that identifies the error in the Lerian error catalog. Built as https://errors.lerian.studio/v1/<code>.
  • title – The HTTP status text, for example Unprocessable Entity.
  • status – The HTTP status code.
  • detail – Text about this occurrence of the condition. The wording comes from the branch that raised it.
  • code – A stable identifier for the condition. Branch on this value.
  • errors – Optional list of per-field validation details, each with a message, a location, and the value found there.
At status 500, 502 and 503 the detail member carries a fixed text instead of a description of your request, so read code to identify the condition. The flat body carries code, title, message, and an optional details object. It never carries type, status or detail. Five codes reach you as a flat body when the idempotency check raises them: PBP-0002, PBP-0007, PBP-0008, PBP-0012 and PBP-0013. The pipeline also answers this way for a failure that no handler caught. So read the media type rather than the code to tell the two bodies apart.

Platform errors


These codes are not specific to one rail. The transport layer, the request pipeline and the handlers raise them.

Provider errors


These codes carry the payment provider’s answer. What is safe to resend depends on the operation, so read the operation’s error descriptions in the API reference before you resend.

Boleto errors


These codes answer the boleto rail: issuance, installments, cancellation and PDF retrieval.

Payment errors


These codes answer the bill payment rail: bankslip, utilities, DARF and the bill consult.

Ledger errors


These codes carry the ledger’s side of a payment. What is safe to resend depends on the operation, so read the operation’s error descriptions in the API reference before you resend.

Webhook configuration errors


These codes answer a request that configures where this API pushes event notifications.

Inbound provider webhook errors


These four codes answer the payment provider that posts settlement events to the webhook endpoint. They tell that caller which repair its delivery needs.