Por que webhooks
Webhooks eliminam a necessidade de polling. Em vez de consultar o status repetidamente, o kycert notifica o seu servidor assim que o run é concluído. O endpoint recebe uma requisição POST com o resultado completo — você processa e responde em milissegundos.Configuração
No dashboard kycert, vá em Integrações & API → Webhooks e cadastre a URL do seu endpoint. Alternativamente, passewebhook_url diretamente no POST /runs para sobrescrever o padrão por requisição.
Requisitos do endpoint
- HTTPS obrigatório em produção (HTTP aceito apenas em sandbox)
- Responder
2xxem até 30 segundos - Idempotente — o mesmo evento pode ser entregue mais de uma vez
Eventos disponíveis
Runs reprovados por regra crítica chegam via
run.completed com status: "blocked" e decision: "rejected". O evento run.failed indica exclusivamente falhas técnicas — nunca reprovações por regra de negócio.Estrutura do payload
run.completed — aprovado
run.completed — reprovado por regra crítica (blocked)
run.failed — falha técnica irrecuperável
Política de retry
Se o seu endpoint retornar um status fora de2xx ou não responder em 30 segundos, o kycert tenta novamente com backoff linear:
Após 3 tentativas sem sucesso (total ~15 min), o evento é marcado como
failed e nenhuma nova tentativa é realizada. O histórico de tentativas fica disponível no dashboard em Integrações & API → Webhooks → Entregas.
Deduplicação
O campoid do evento é único. Armazene os IDs processados para ignorar duplicatas em caso de retry:
Headers do webhook
Cada requisição de webhook inclui os seguintes headers:Verificação de assinatura
Todo webhook inclui o headerkycert-signature. Sempre verifique — qualquer servidor pode fazer POST para o seu endpoint.
Consulte Segurança para o procedimento completo de verificação com exemplos em 3 linguagens.
Sandbox
Em sandbox, os webhooks são entregues normalmente. Use um serviço como webhook.site ou ngrok durante o desenvolvimento. O campolivemode: false identifica eventos de sandbox.