Saltar para o conteúdo principal
A API da Didit comunica uma falha com um código de estado HTTP e, quase sempre, com um corpo em JSON. Esta página indica o que significa cada estado, como é o corpo, que valores de code podem usar para decidir e quais as falhas que permitem tentar novamente em segurança. Baseie-se primeiro no estado e, quando existir, no code, porque o texto de uma mensagem pode mudar.

Códigos de estado

Corpos de erro

Os corpos de erro não seguem um formato comum, por isso deve tratá-los com cautela. O formato depende da família do endpoint: Um 500 pode não ter nenhum corpo JSON, por isso trate um corpo que não possa ser interpretado.

Erros de chave de API

Durante alguns minutos após a eliminação de uma aplicação, a API responde com application_deleted. Depois disso, recusa a chave como faria com qualquer chave errada. Não repita o pedido: a aplicação e as suas chaves foram eliminadas. Veja Autenticação da API e Chaves de API para saber como funcionam as chaves e os respetivos limites.

Créditos insuficientes

Cada família de APIs comunica um saldo baixo à sua maneira: Num contrato, a criação de uma sessão responde com 403 e "code": "contract_billing_suspended" enquanto os serviços pagos da sua organização estiverem suspensos. As aplicações sandbox nunca são cobradas, por isso não passam por estas verificações.

Códigos de erro

Estes valores de code são estáveis, por isso pode usá-los para ramificar a lógica do seu código. A maioria aparece junto de detail; na verificação de carteiras de identidade digital, o código é o valor de error.

Acesso e faturação

Pedidos e idempotência

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

Verificação de empresas (KYB)

Carteiras de identidade digital

Relatórios e casos

Assinaturas eletrónicas

Na criação da sessão, os problemas com o documento indicados abaixo chegam como valor do campo em causa, com estado 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 pelo cabeçalho Retry-After e, em seguida, tente novamente.
  • 502 e 503: tente novamente com recuo 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 este estado, por si só, não significa uma falha temporária.
  • 503 numa eliminação: repita o mesmo pedido até obter 200.
  • Outros 4xx: corrija primeiro o pedido, porque o mesmo pedido falha sempre da mesma forma.
POST /v3/aml/ e a verificação de carteira Digital ID aceitam um cabeçalho Idempotency-Key com até 255 caracteres. Repetir um pedido com a mesma chave e o mesmo corpo devolve a resposta guardada, pelo que o trabalho e a cobrança são executados apenas uma vez. A mesma chave com um corpo diferente devolve 409, e enquanto o primeiro pedido ainda estiver em execução, os endpoints de carteira devolvem 409 com Retry-After. POST /v3/session/ não tem chave de idempotência, por isso, se a criação exceder o tempo limite, liste as suas sessões por vendor_data antes de criar outra.

Relacionados

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