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