Release an end user's DICT key queries

Releases a block once the operator has established that the behaviour was justified, or that the suspicion no longer holds: the end user’s key queries are served again, subject to the section 13.1 buckets that never stopped applying. Same posture as placing it — one identified operator, mandatory justification, audited under their identity. Idempotent: an end user carrying no block answers 200 with alreadyApplied.

DELETE /api/v1/dict/internal/query-blocks

Release an end user's DICT key queries

cURL

curl --request DELETE \
  --url https://api.example.com/api/v1/dict/internal/query-blocks \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "justification": "<string>",
  "payerId": "12345678901"
}
'

200

{
  "blocked": true,
  "payerId": "12345678901",
  "alreadyApplied": true
}

Autorizações

Authorization · string · header · obrigatório

JWT bearer token issued by the identity provider.

Corpo

application/json

justification · string · obrigatório

Why this end user is being blocked or released — the verified suspicion section 13.2.3 conditions the act on, in the operator's own words. Recorded in the audit trail under the caller's identity. Operator prose only: never a tax id, a Pix key, an account or a holder name.

Required string length: 8 - 384

payerId · string · obrigatório

The end user's CPF (digits) or CNPJ (alphanumeric, IN RFB 2.229/2024) — the same identifier their key queries carry in PI-PayerId and the monitor read reports.

Pattern: ^([0-9]{11}|[A-Za-z0-9]{12}[0-9]{2})$

Exemplo:

"12345678901"

Resposta

200

application/json

OK

blocked · boolean · obrigatório

Whether this end user's DICT key queries are blocked after the call.

Exemplo:

true

payerId · string · obrigatório

CPF or CNPJ of the end user this call acted on.

Exemplo:

"12345678901"

alreadyApplied · boolean

True when the end user was already on the requested side and nothing changed. The call is a success either way and is still audited under the caller's identity, so re-sending a request whose response was lost is safe.