Skip to main content
POST
Create a static PIX QR code

Authorizations

Authorization
string
header
required

JWT bearer token issued by the identity provider.

Body

application/json
accountId
string
required

The CRM account id of the recipient (sources name + city).

Example:

"acc-123"

amount
integer<int64>
required

Amount in centavos (an integer; 0 = any-amount static QR).

Example:

10050

key
string
required

The recipient PIX key the static QR pays into.

Example:

"recipient@bank.com"

description
string

Free-text additional data (dadosAdicionais).

Example:

"Invoice 42"

ispb
string

The ISPB of the direct participant that mints this QR. This deployment may act as SEVERAL direct SPI participants - one ISPB each, each with its own customers and its own JDPI credential - and this field is the only thing on the request that says which of them acts. OPTIONAL while it acts as a single participant: omit it and that one acts. REQUIRED once it acts as several - omitted is 422 PIX-0127, and an ISPB this deployment does not act as is 422 PIX-0128. It is ROUTING DATA you supply and guarantee, exactly like payerIspb on a transaction: never a credential, never read from a header or a path, and it never widens what your token can reach. Send it as an absent key, not an empty string; an empty value is refused 400 PIX-0061.

Pattern: ^[0-9]{8}$
Example:

"12345678"

txId
string

Conciliation id (idConciliacaoRecebedor); §8.3.1 caps it at 25 characters and states no charset (default "***").

Example:

"TX-001"

Response

Created

qrCode
string
required

The generated EMV QR-code payload (base64-decoded, ready to render).

Example:

"00020126..."

documentId
string

The JDPI charge GUID (idDocumento) addressing the update leg (dynamic only).

Example:

"52c43361-caa1-4ddb-9152-708426a25db3"

payloadJws
string

The signed JWS payload, returned ONLY when the QR was generated under an indirect participant's own certificate — that indirect hosts it at payloadUrl on its own infrastructure. Absent on the direct path, where the plugin self-hosts it. It is returned ONCE and never stored: if this response is lost, do NOT re-create (the same recipientConciliationId is refused as a duplicate) — read the charge's documentId from GET /v1/qrcodes/list and re-sign it via PUT /v1/qrcodes/dynamic/{documentId} with the same indirectId, which returns a fresh payloadJws on a fresh payloadUrl.

Example:

"eyJhbGciOiJFUzI1NiJ9.eyJyZXYiOjB9.sig"

payloadUrl
string

The resolvable JWS host URL the dynamic QR embeds (urlPayloadJson; schema-less; dynamic only).

Example:

"pix.example.com/qr/cob/fzqRwuXYSweWofLD1OX2Bw"