Skip to main content
Error format The Pix JD API answers a failed request with application/problem+json. The Detail schema in this API reference describes that body, which follows RFC 9457.
Field definitions
  • code – Stable, machine-readable domain error code scoped to the emitting service. On this API it has the form PIX-NNNN.
  • title – A short, human-readable summary of the problem type. This value should not change between occurrences of the error.
  • detail – A human-readable explanation specific to this occurrence of the problem.
  • status – The HTTP status code.
  • type – A URI that identifies the error in the Lerian error catalog, built as https://errors.lerian.studio/v1/<code>.
  • instance – A URI reference that identifies the specific occurrence of the problem.
  • errors – An optional list of field-level details. Each entry carries the location that failed, a message, and the value at that location.
  • upstream – An RFC 9457 extension member. It carries the code and message a proxied third-party provider reported, and it is absent unless the service surfaced one.
How to read these tables Each row starts with the HTTP status the response carries. Then it names the condition. The last column gives the detail text the service sends by default. Where the service composes that text from the failing request, the row says so. At status 500 and above the response carries fixed text, not the raw cause. The detail column shows whether a code sends internal error or a sentence the service wrote for it.

Pix service request and business rules


These codes come from the Pix service itself. They cover request validation, Pix key management, key claims, payment orders, returns, QR codes, indirect participants, and inbound credits.

Request validation and access

Pix keys

Pix key claims

Transactions and payments

Returns and refunds

Participants and accounts

QR codes

Entities, templates and conciliation

Fraud, compliance and regulation

Service and dependency faults

Tenant configuration

Indirect participants

Inbound credits

Pix rail and key directory


These codes come from the connected Pix infrastructure. The service translates a rail fault into one of these codes before it answers. A caller branches on a PIX-NNNN value, not on the rail’s own vocabulary.

Request validation and authentication

Pix keys

Pix key claims

Transactions and payments

Returns

Participants and accounts

QR codes

Rail availability

Fraud, compliance and regulation

Failures that originate outside the Pix rail


A Pix request can also fail because another platform service refused it. Three code bands carry those refusals: customer records, authorization, and the Midaz ledger.

Customer records

Authorization

Ledger

Notification delivery


The Pix key ownership flows send a one-time code by email or by SMS. These codes report a failure on that delivery leg.

Email delivery

SMS delivery

MED refund rejection reasons


A MED refund request that this participant analyzes and rejects carries a numbered rejection reason. The domain uses the values 0, 1, 3 and 4.

Pix return reason codes


A returned Pix carries a Bacen return reason of its own, separate from the PIX-NNNN codes above. This API reference documents the allowed values on the field that carries them. That field is codigoDevolucao on an inbound credit and on the refund credit status view. On a refund request it is code.