Delete a PIX key entry
Removes a PIX key from the DICT directory and hides every live local row of the key in this participant, whichever account of the holder it names, except another holder’s pending ownership confirmation. entryId is the key VALUE, URL-encoded; the body carries accountId.
Two ownership gates run before anything is deleted, and both fail closed. The key must appear in the account’s own §8.2.06 directory listing, and §8.2.14 must report it held by this ISPB and account number - a key held by anyone else is 403 PIX-0018, and an ownership check that could not complete refuses with the upstream cause rather than claiming the key is not yours. If DICT reports the key does not exist at all, no delete is sent: stale local rows are hidden so the listing stops advertising the key, and with no local row on this account either the call is 403 PIX-0018. A key whose registration never got an answer (a pending record at status 8) that the account’s directory listing does not show was never registered: once that registration is older than its own time limit (about one minute), the pending record is released, this account’s other local rows of the key are hidden as stale (a claim in progress is left to the claim flow), and the call succeeds; before that the registration may still land, and the call is 409 PIX-0007 - retry it a minute later.
Order matters for recovery. DICT is deleted FIRST, then the local rows are soft-deleted (deleted_at is set and the status column is left alone, so nothing marks the row as cancelled). A failure between the two steps leaves the key gone upstream while a local row keeps surfacing in GET /v1/entries with its stale status; re-issuing the DELETE through the same account finishes that account’s cleanup: §8.2.14 reports the key gone, so the account’s stale rows are hidden (a claim in progress is left to the claim flow) and the call succeeds. Another account’s stale row of the key is cleaned by a DELETE through that account. A row still pending registration follows its own rule: once its time limit passes, the retry releases it and succeeds, as described above. The DICT deletion itself cannot be undone through this API - register the key again with POST /v1/entries.
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. 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 PIX key value (URL-encoded).
"11122233300"
Body
The CRM account id of the key owner.
"acc-123"
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-9]{8}$"12345678"
Response
OK
The PIX key that was deleted.
"11122233300"