Skip to main content
DELETE
Delete PIX key

Autorizaciones

Authorization
string
header
requerido

JWT bearer token issued by the identity provider.

Encabezados

X-Idempotency
string
requerido

Idempotency key, max 255 characters

Cuerpo

application/json

PIX key value to delete; only ACTIVE or INACTIVE keys are deletable

keyValue
string
requerido

PIX key value identifying the key to delete, in its canonical format for the key type. At most 77 characters, the ceiling BACEN publishes on a DICT key.

Required string length: 1 - 77
Ejemplo:

"12345678901"

participantISPB
string
requerido

ISPB of the participant the key is bound to. Must be the key's stored owning participant and a participant this deployment is authorized to act for; any other value is rejected.

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

"12345678"

reason
enum<string>

Deletion reason reported to BACEN, defaulting to USER_REQUESTED; the enum is the set deleteEntry accepts. FRAUD and RFB_VALIDATION are MANDATED by DICT 8.4 section 4.1 for a removal forced by incompatibility with the Receita Federal registry — FRAUD when the name divergence or the irregular CPF/CNPJ is fraud, RFB_VALIDATION in the other cases. ACCOUNT_CLOSURE, RECONCILIATION, FRAUD and RFB_VALIDATION are participant-initiated (sections 4.4/4.5): no end user asks, so requesterTaxId is not demanded for them.

Opciones disponibles:
USER_REQUESTED,
ACCOUNT_CLOSURE,
RECONCILIATION,
FRAUD,
RFB_VALIDATION
Ejemplo:

"USER_REQUESTED"

requesterTaxId
string

CPF or CNPJ of the END USER asking for the removal. MANDATORY when reason is USER_REQUESTED (the default): DICT 8.4 section 4.2 obliges the PSP to check that the user requesting the exclusão is the user the key is bound to, and the DICT re-checks it ("chave deve pertencer ao usuário que solicitou a exclusão"). Omitted for the PSP-initiated reasons — ACCOUNT_CLOSURE, RECONCILIATION, FRAUD, RFB_VALIDATION — where no end user is asking; supplied on any of them it is still compared against the stored owner. A value that does not match the stored owner is refused with the same answer as an unauthorized participant, so this route cannot be used to discover who owns a key.

Ejemplo:

"12345678901"

Respuesta

No Content