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 decode 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çalhoRetry-Aftere, em seguida, tente novamente.502e503: 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.502emPOST /v3/database-validation/: leia primeiro cada entrada devalidation_errors, porque este estado, por si só, não significa uma falha temporária.503numa eliminação: repita o mesmo pedido até obter200.- 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
- Limitação de pedidos: limites, cabeçalhos e o corpo do
429. - Autenticação da API: como enviar a sua chave.
- Testes no sandbox: reproduza resultados sem dados reais nem cobrança.
- Webhooks: entrega, novas tentativas e ordem.