Register a PIX key entry
Registers a PIX key for the account named by accountId, and is also the only entry point to the claim flow. keyType must agree with the value in key (0=CPF, 1=CNPJ, 2=EMAIL, 3=PHONE, 4=RANDOM) or the call is 422 PIX-0010 naming the expected and detected types; omit key for RANDOM and DICT mints the EVP value (§8.2.01). isValidated is accepted but ignored - the service always restarts validation.
An unvalidated EMAIL or PHONE key never reaches DICT on this call: the service stores it locally as awaiting ownership confirmation (status 2), sends a 6-digit code to that address, and answers with status 2. Finish it with POST /v1/entries//confirmation. Calling this route again for the same key re-arms the row with a NEW code and the previous one stops working. A key of those two types that the account already holds at DICT is 409 PIX-0071. CPF, CNPJ and RANDOM keys go straight to DICT.
If DICT answers that the key is already registered elsewhere, the call still SUCCEEDS: the service records a claim-pending row (status 4) carrying the claim type DICT implied - portability when the current holder’s document matches yours, possession otherwise (§8.2.07) - and no claim is opened yet. Opening it is POST /v1/claims, which works only on a row this call created. The whole operation is idempotent on (accountId, key): an existing live row is returned with its current status rather than registered a second time.
Authorizations
JWT bearer token issued by the identity provider.
Body
The CRM account id of the key owner.
"acc-123"
Numeric eKeyType (0=CPF,1=CNPJ,2=EMAIL,3=PHONE,4=RANDOM).
2
Ignored: the service always forces validation to start fresh.
false
The PIX key value (omit for a RANDOM key).
"foo@bar.com"

