Pular para o conteúdo principal
A API do Didit informa uma falha com um código de status HTTP e, em quase todos os casos, com um corpo JSON. Esta página lista o que cada status significa, qual é o formato do corpo, quais valores de code você pode usar em desvios condicionais e quais falhas podem ser tentadas novamente com segurança. Baseie-se primeiro no status e depois em code, quando ele estiver presente, porque o texto de uma mensagem pode mudar.

Códigos de status

Corpos de erro

Os corpos de erro não compartilham um único formato, então leia-os de forma defensiva. O formato depende da família de endpoints: Um 500 pode não ter nenhum corpo JSON, então trate um corpo que não possa ser analisado.

Erros de chave de API

Durante alguns minutos após a exclusão de uma aplicação, a API responde com application_deleted e, depois disso, recusa a chave como qualquer chave errada. Não tente novamente: a aplicação e suas chaves foram excluídas. Consulte Autenticação da API e Chaves de API para entender como as chaves e seus limites funcionam.

Créditos insuficientes

Cada família de APIs informa saldo insuficiente de uma forma diferente: Em um contrato, a criação de uma sessão retorna 403 com "code": "contract_billing_suspended" enquanto os serviços pagos estiverem pausados para sua organização. Aplicações sandbox nunca são cobradas, por isso não são submetidas a essas verificações.

Códigos de erro

Estes valores de code são estáveis, então você pode tomar decisões condicionais com base neles. A maioria aparece ao lado de detail; na verificação com carteiras de Digital ID, o código é o valor de error.

Acesso e faturamento

Requisições e idempotência

Verificações bancárias, de telefone e de risco

Verificação de empresas (KYB)

Carteiras de Digital ID

Relatórios e casos

Assinaturas eletrônicas

Na criação da sessão, os problemas de documento abaixo chegam como o valor do campo com problema, com status 400, por exemplo {"sign": "signature_document_changed"}:

Webhooks

Novas tentativas e idempotência

Algumas falhas podem ser repetidas com segurança e outras não:
  • 429: aguarde o tempo indicado no cabeçalho Retry-After e tente novamente.
  • 502 e 503: tente novamente com backoff quando a referência do endpoint indicar que nada foi cobrado, como acontece nas verificações de telefone, e-mail, bancárias e de risco.
  • 502 em POST /v3/database-validation/: leia primeiro cada entrada de validation_errors, porque esse status sozinho não significa uma falha temporária.
  • 503 em uma exclusão: repita a mesma requisição até que ela retorne 200.
  • Outros 4xx: corrija a requisição primeiro, porque a mesma requisição falha da mesma forma.
POST /v3/aml/ e a verificação da carteira Digital ID aceitam um cabeçalho Idempotency-Key de até 255 caracteres. Repetir uma requisição com a mesma chave e o mesmo corpo reproduz a resposta armazenada, de modo que o processamento e a cobrança acontecem uma única vez. A mesma chave com um corpo diferente responde 409, e, enquanto a primeira requisição ainda estiver em execução, os endpoints de carteira respondem 409 com Retry-After. POST /v3/session/ não tem chave de idempotência; por isso, se uma requisição de criação atingir o tempo limite, liste suas sessões por vendor_data antes de criar outra.

Conteúdos relacionados

Última modificação em 1 de novembro de 2026