Skip to main content

Visão Geral

Os eventos de webhook KYC permitem que você receba notificações em tempo real quando o status de uma verificação KYC mudar. Gu1 envia automaticamente solicitações HTTP POST para seu endpoint de webhook configurado sempre que um status de validação é atualizado, permitindo que você automatize fluxos de trabalho de integração de clientes e mantenha a conformidade.

Por Que Usar Webhooks KYC?

Atualizações em Tempo Real

Receba notificações instantâneas quando o status de verificação mudar

Eficiente

Não é necessário consultar a API repetidamente

Fluxos de Trabalho Automatizados

Atualize automaticamente contas de usuário com base nos resultados de verificação

Melhor UX

Notifique clientes imediatamente após a verificação

Eventos Disponíveis

Gu1 envia webhooks para os seguintes eventos de validação KYC:

Estrutura do Payload do Evento

Todos os webhooks KYC usam o mesmo envelope externo. O objeto payload é o registro de validação KYC armazenado no Gu1 (mesmos nomes de campo que no banco/API: id é o UUID da validação, além de entityId, organizationId, status, decision, extractedData, verifiedFields, warnings, metadata, timestamps, etc.).
O campo entity (linha completa da entidade no Gu1) é enviado somente em estados finais: kyc.validation_approved e kyc.validation_rejected. Não é incluído em created, in_progress, in_review, abandoned, expired ou cancelled. É um campo adicional: os demais campos do payload permanecem iguais. Em kyc.validation_approved, o preenchimento automático opcional da pessoa a partir do KYC continua depois do webhook (mesma ordem de antes); payload.entity é um instantâneo no momento do envio (antes desse passo). Para o estado após o preenchimento automático, use a API de entidades.
Quando presente, payload.entity inclui todas as colunas da entidade (JSON seguro, datas em ISO).

Campos comuns do envelope

string
O tipo de evento (por exemplo, kyc.validation_approved)
string
Timestamp ISO 8601 quando o evento ocorreu
string
Seu ID de organização
string
ID da validação KYC no Gu1 (chave primária do registro)
string
O ID da entidade (pessoa) sendo verificada
object
Apenas em kyc.validation_approved e kyc.validation_rejected. Instantâneo da linha da entidade no Gu1 no momento do envio (na aprovação, antes do preenchimento automático opcional).
string
Status atual de validação: pending, in_progress, in_review, approved, rejected, abandoned, expired, cancelled

Objeto decision (payload.decision)

Quando uma validação atinge um estado terminal ou in_review com resultados do provedor, payload.decision contém o resultado completo do fluxo KYC. O Gu1 sempre persiste e devolve ambas as formas por feature: objeto singular (legacy) e array de um elemento (atual). Você pode ler id_verification ou id_verifications[0]; eles ficam sincronizados. O mesmo vale para liveness / liveness_checks, face_match / face_matches, aml_screening / aml_screenings e ip_analysis / ip_analyses. Campos de mídia (front_image, reference_image, images.*, etc.) são chaves de armazenamento Gu1 (kyc/...) após o ingest. Obtenha-as via a API de mídia de validação. Registros antigos podem ainda ter URLs HTTPS de curta duração até sincronizar. Exemplo aprovado (completo):
Exemplo rejeitado (completo):

Payloads Específicos de Eventos

kyc.validation_created

Enviado quando uma nova validação KYC é criada. entity não é incluído (evento não terminal).
Caso de uso: Envie a URL de validação para seu cliente via email ou SMS.

kyc.validation_in_review

Enviado quando um cliente completa a verificação e requer revisão manual da equipe de compliance. entity não é incluído.
Caso de uso: Notifique a equipe de compliance para revisão manual. Atualize a UI para mostrar “Em revisão pela equipe de compliance”.

kyc.validation_approved

Enviado quando a verificação é concluída com sucesso. entity é incluído (linha completa no momento do envio; o preenchimento automático opcional pode rodar depois, como antes).
Campos adicionais: entity contém todas as colunas da entidade no Gu1 no momento do envio. Caso de uso: Ative a conta do cliente e conceda acesso aos serviços.

kyc.validation_rejected

Enviado quando a verificação falha. entity é incluído.
Caso de uso: Notifique o cliente que a verificação falhou e forneça orientação sobre os próximos passos.

kyc.validation_cancelled

Enviado quando uma validação é cancelada manualmente pela organização. entity não é incluído.
Caso de uso: Notifique o cliente que a validação foi cancelada. Limpe recursos associados e atualize o status no seu sistema.

Exemplos de Código

Node.js - Lidando com Eventos KYC

Melhores Práticas

O webhook inclui entity.externalId que é o ID que você forneceu ao criar a entidade. Use-o para buscar o cliente no seu banco de dados.
Armazene o validationId do Gu1 no seu banco de dados. Isso permite que você consulte detalhes de validação mais tarde, se necessário.
Você pode receber o mesmo webhook múltiplas vezes. Use o validationId para garantir que você processe cada evento apenas uma vez.
Sempre retorne um código de status 200 o mais rápido possível para confirmar o recebimento. Processe o webhook assincronamente se necessário.
Sempre verifique o header X-Webhook-Signature para garantir que o webhook seja autêntico. Veja o guia de segurança para detalhes.

Solução de Problemas

Verificar estes itens:
  • URL do webhook é publicamente acessível via HTTPS
  • Webhook está configurado e habilitado no dashboard
  • Inscrito nos tipos de eventos KYC corretos
  • Endpoint retorna código de status 200 dentro de 30 segundos
  • Verificar logs do servidor para solicitações recebidas
extractedData e verifiedFields são incluídos apenas em:
  • kyc.validation_approved
  • kyc.validation_rejected
Eles não estão presentes em outros tipos de eventos como validation_created ou validation_in_progress.
Causas comuns:
  • Usar secret errado (verificar dashboard para secret atual)
  • Verificar assinatura em JSON analisado em vez de corpo raw
  • Re-verificar a partir do JSON do monitor de webhooks (pretty-print / JSON.stringify ≠ bytes assinados)
  • Middleware que altera o body antes de verificar (alguns payloads falham, outros passam)
  • Secret não salvo corretamente após criação do webhook
  • Problemas de codificação (garantir UTF-8)
Veja Segurança de webhooks — especialmente Corpo raw vs JSON analisado, Histórico no dashboard e Falhas intermitentes de assinatura.
Este é um comportamento normal. Webhooks podem ser enviados múltiplas vezes devido a problemas de rede, timeouts ou tentativas.Sempre implemente idempotência usando o validationId do webhook e tipo de event.

Próximos Passos

Eventos de Entidades

Lidar com eventos de ciclo de vida de entidades

Eventos de Regras

Processar acionamentos de regras de conformidade

Segurança de Webhooks

Proteger seus endpoints de webhook

Configuração

Configurar ajustes de webhook