⚠️ Important: To use this endpoint, include the header X-Trace-Version with the value 2.
DICT Key Types and Requirements The DICT Key must be one of the following valid types: CNPJ, CPF, email, phone number, or UUID version 4. Each type has specific formatting and validation rules as outlined below.
| Key Type | Requirement | Validation Pattern |
|---|---|---|
| CNPJ | No formatting; must contain 14 characters | 14 numeric characters only |
| CPF | No formatting; must contain 11 characters | 11 numeric characters only |
| Must be a valid email format | Standard email validation | |
| Cellphone | Must follow international format with '+' prefix | ^\+[1-9]\d{1,14}$ |
| UUID v4 | Must be a valid UUID version 4 | Standard UUID v4 validation |
Protection Feature To safeguard the system against misuse and to prevent depletion of user tokens from BACEN's DICT control, a protection mechanism is implemented. If an invalid DICT Key is submitted, it will automatically be added to a blacklist for a duration of one hour. This feature helps to prevent repeated attempts with invalid keys.
Cache Mechanism To prevent potential blocks from the BACEN DICT Control, the system caches bank account data after the first transaction using a specific DICT Key. Subsequent transactions with the same DICT Key utilize the cached data, returning a transaction type of BANK_INSTRUCTION instead of DICT_KEY.
Asynchronous Enrichment
In the response of this request, both endToEnd and destination fields will be returned as null. These fields will be asynchronously populated at a later stage of the processing cycle. Additionally, due to the asynchronous nature of this processing, the transaction will initially be returned with REQUESTED status. Once the necessary data has been populated and the transaction has progressed, the status will be updated accordingly in subsequent stages.