Confirm a PIX key claim
Accepts a claim someone opened on YOUR key: you are the DONOR - the Cliente Doador - agreeing to hand it over (§8.2.10). claimId is in the path; the body carries key and accountId.
The donor holds no claim row of its own, so the claim is read from DICT first (§8.2.15) and every check runs BEFORE the confirmation, which has no undo: DICT must state the claim as one this account answers as holder - ispbDoador is the caller’s participant, the claim is about the key in the body, and dadosDoador, when sent, names the caller’s account - else 404 PIX-0020; and the key must be the caller’s, by its local row or by the account’s §8.2.06 listing, else 404 PIX-0069. The claim must be open (situation 0 or 1), else 422 PIX-0073; one DICT already holds Confirmed is a retry of a confirmation whose answer was lost, answered 200 without confirming again. One DICT holds Completed (4) is that same retry after the claimer concluded, answered 200 only when the account’s §8.2.06 listing no longer holds the key: nothing is sent to DICT and your key row, if any, ends DONATED and soft-deleted. While the listing still holds the key it is 422 PIX-0073. A row already at the donor status 6 takes exactly the same checks - there is one way to confirm as donor, always verified at DICT - and any other status of the caller’s row, such as a CLAIMER’s own row at status 5, is 422 PIX-0073 with nothing sent to DICT.
DICT is sent reason 0 (user request), the only value §8.2.10 accepts in both donor columns. On success your key row becomes DONATED (3) and is kept: the key stays at DICT on your account until the claimer concludes, and a later cancellation or lapse of the claim brings it back to ACTIVE.
Which of this deployment’s direct participants writes to the national directory is decided by ispb, by exactly the rule an order’s payerIspb follows: this deployment may act as several direct participants, each with its own ISPB and its own DICT credential, and naming none is answerable only while there is one answer. Omit it while this deployment acts as a single participant; once it acts as several, omitting it is 422 PIX-0127 and naming one it is not is 422 PIX-0128. When the account named on the request cannot be used by that participant, the request is refused before the operation acts and the answer names the account: 422 PIX-0137 when it is held in a ledger that is not configured for Pix, 422 PIX-0138 when its record does not say which ledger holds it, and 422 PIX-0139 when its record names a different institution. A key written under the wrong participant is declared to Bacen by the wrong institution, and there is no undo.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
The claim id.
"claim-123"
Body
The Midaz ledger account id of the caller.
"019a1b2c-3d4e-7f60-8a9b-0c1d2e3f4a5b"
The PIX key the claim targets.
"11122233300"
The ISPB of the direct participant this operation acts as. This deployment may act as SEVERAL direct SPI participants - one ISPB each, each with its own customers and its own DICT credential - and this field is the only thing on the request that says which of them writes to the national directory. 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. It also selects the DICT credential the call goes out on, so a key registered under the wrong one is declared to Bacen by the wrong institution. Send it as an absent key, not an empty string; an empty value is refused 400 PIX-0061.
^[0-9A-Z]{8}$"12345678"