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 decode 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çalhoRetry-Aftere tente novamente.502e503: 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.502emPOST /v3/database-validation/: leia primeiro cada entrada devalidation_errors, porque esse status sozinho não significa uma falha temporária.503em uma exclusão: repita a mesma requisição até que ela retorne200.- 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
- Limite de requisições: limites, cabeçalhos e o corpo do
429. - Autenticação da API: como enviar sua chave.
- Testes no sandbox: reproduza resultados sem dados reais nem faturamento.
- Webhooks: entrega, novas tentativas e ordem.