Skip to main content
PUT
Update an immediate dynamic PIX QR code

Authorizations

Authorization
string
header
required

JWT bearer token issued by the identity provider.

Path Parameters

documentId
string
required

The existing charge GUID to update (JDPI idDocumento).

Example:

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

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).

Example:

10050

key
string
required

The recipient PIX key the dynamic QR pays into.

Example:

"recipient@bank.com"

recipientConciliationId
string
required

Conciliation id (idConciliacaoRecebedor); §8.3.5 mandatory; 26..35 alphanumeric ([a-zA-Z0-9]).

Example:

"JDPI2020010300000000000000000000001"

status
integer<int64>
required

Charge status: 0=Active, 1=Concluded, 2=Removed by recipient, 3=Removed by PSP.

Example:

0

description
object[] | null

Optional additional-data entries (dadosAdicionais).

expirationTime
integer<int64>

QR expiration in seconds (0 = JDPI default).

Example:

3600

indirectId
string<uuid>

Optional identifier (UUID) of an indirect participant registered here, mirroring the create body. Supply the SAME institution the charge was generated for: the plugin stores no indirect association for a QR, so an omitted value re-signs the charge under the DIRECT participant's certificate and moves its location onto the direct participant's domain. Refused 422 PIX-0111, naming the setting to enable, while this tenant's indirect-participants feature is off: routing you supply is never silently dropped.

Example:

"3f2504e0-4f89-41d3-9a0c-0305e82c3301"

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. The published payloadUrl and its JWKS location are built under this participant's ISPB, so a QR minted as the wrong one points every payer's PSP at a key set that cannot validate its signature. When indirectId is supplied this must be blank or the participant recorded at that indirect's registration, which is NOT necessarily this deployment's default one; naming any other is 422 PIX-0102. Send it as an absent key, not an empty string; an empty value is refused 400 PIX-0061.

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

"12345678"

payer
object

Optional payer block.

zipCode
string

Recipient postal code (cep).

Example:

"01310100"

Response

OK

qrCode
string
required

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

Example:

"00020126..."

revision
integer<int64>
required

The JDPI-computed charge revision (revisao).

Example:

2

payloadJws
string

The re-signed JWS payload, returned ONLY when the update ran under an indirect participant's own certificate. Absent on the direct path.

Example:

"eyJhbGciOiJFUzI1NiJ9.eyJyZXYiOjJ9.sig"

payloadUrl
string

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

Example:

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