Webhook
Documentação de Webhooks
Objetivo
Os webhooks permitem que seu sistema receba notificações em tempo real à medida que avança uma operação de verificação:
início da operação,
capturas de evidência (documento, selfie, NFC),
avaliações biométricas,
resultado final.
Com isso, você pode atualizar estados de negócio, disparar regras e mostrar rastreabilidade ao usuário final sem consultar continuamente por polling.
Como funciona o envio
Você configura uma URL HTTPS de recepção na sua integração.
O sistema envia eventos por
POSTcom payload JSON.Somente os eventos aos quais você se inscreveu na sua configuração são enviados.
Cada mensagem inclui assinatura para validar a autenticidade.
Recomendação para seu Endpoint:
responder rapidamente com
2xxquando a mensagem for aceita,processar de forma assíncrona quando possível,
lidar com idempotência usando
iddo evento.
Segurança e autenticidade
Cada webhook inclui:
cabeçalho
Content-Type: application/json,cabeçalhos de segurança personalizados (se você os definiu),
campo
signaturedentro do payload.
A assinatura é calculada com HMAC SHA-256 sobre o conteúdo do evento e uma chave compartilhada de integração. Você deve validar essa assinatura antes de considerar a mensagem como confiável.
Estrutura geral do webhook
Todos os eventos seguem a mesma estrutura base:
Significado dos campos:
id: identificador único da mensagem (usar para evitar duplicados).type: tipo de evento (define como interpretardata).source: operação de origem do evento.time: data/hora UTC de emissão.data: conteúdo de negócio do evento.signature: assinatura da mensagem.
Base em TypeScript
Todos os eventos compartilham este envelope base:
Notas de modelagem:
specversionhoje é sempre"1.0".id,timeesignaturenão têm catálogo fechado.sourcesempre segue o padrão/operations/{operationId}.Em cada evento, são fechados como enum apenas os valores que a implementação atual fixa de forma explícita.
Quando um provedor externo ou uma etapa interna não fixa um catálogo fechado, o campo deve ser deixado como
string,Record<string, unknown>ou uma estrutura aberta equivalente.
Eventos disponíveis atualmente
1) Operação iniciada
Tipo:
com.idv_suite.api.workflows.operation_started.v1Quando é enviado: ao criar/iniciar uma operação.
Para que serve: abrir o acompanhamento da operação e correlacionar com seus sistemas.
Tipagem TypeScript:
Exemplo:
2) Consentimento de termos
Tipo:
com.idv_suite.api.workflows.terms_consent.v1Quando é enviado: ao aceitar ou recusar termos.
Para que serve: rastreabilidade legal e regras de continuidade do fluxo.
Tipagem TypeScript:
Exemplo:
3) Documento capturado (ID/OCR)
Tipo:
com.idv_suite.api.workflows.id_captured.v1Quando é enviado: ao concluir a captura e extração de dados do documento.
Para que serve: preencher dados documentais e validar a consistência.
Tipagem TypeScript:
Notas:
dataesummarynão têm um schema fechado na implementação atual.assetscontém IDs de assets associados ao evento.
Exemplo:
4) Selfie capturada
Tipo:
com.idv_suite.api.workflows.selfie_captured.v1Quando é enviado: ao concluir a Captura Facial.
Para que serve: marcar avanço de etapa biométrica.
Tipagem TypeScript:
Exemplo:
5) NFC capturado
Tipo:
com.idv_suite.api.workflows.nfc_captured.v1Quando é enviado: quando houver leitura NFC do documento.
Para que serve: enriquecer e contrastar informações documentais.
Tipagem TypeScript:
Notas:
Assim como em
id_captured,dataesummarycontinuam abertos.
Exemplo:
6) Liveness Passivo avaliado
Tipo:
com.idv_suite.api.workflows.passive_liveness_evaluated.v1Quando é enviado: após avaliar teste de vida passivo.
Para que serve: detectar possíveis tentativas de suplantação.
Tipagem TypeScript:
Notas:
diagnosticnão tem enum fechado no código; o exemplo conhecido é"Live".
Exemplo:
7) Detecção de injeção
Tipo:
com.idv_suite.api.workflows.injection_attack_detected.v1Quando é enviado: após avaliar risco de injeção/sintético.
Para que serve: fortalecer controles antifraude em tempo real.
Tipagem TypeScript:
Exemplo:
8) Matching facial avaliado
Tipo:
com.idv_suite.api.workflows.facial_authentication_evaluated.v1Quando é enviado: ao comparar o rosto do documento com a selfie.
Para que serve: validar correspondência biométrica.
Tipagem TypeScript:
Notas:
authStatusnão tem enum fechado no código. O exemplo conhecido é"Positive".
Exemplo:
9) Cadastro facial
Tipo:
com.idv_suite.api.workflows.facial_enrollment.v1Quando é enviado: ao registrar uma identidade biométrica.
Para que serve: habilitar autenticações futuras 1:1.
Tipagem TypeScript:
Exemplo:
10) Verificação facial 1:1
Tipo:
com.idv_suite.api.workflows.facial_verification.v1Quando é enviado: ao validar a identidade contra um cadastro anterior.
Para que serve: autenticação ou confirmação de identidade.
Tipagem TypeScript:
Notas:
authStatuspermanece aberto; o exemplo conhecido é"Positive".assetsneste evento é emitido comostringsimples, não comostring[].
Exemplo:
11) Matching documental avaliado
Tipo:
com.idv_suite.api.workflows.document_matching_evaluated.v1Quando é enviado: ao comparar duas fontes documentais dentro do Fluxo.
Para que serve: medir consistência entre documentos ou entre capturas do mesmo titular.
Tipagem TypeScript:
Exemplo:
12) Operação finalizada
Tipo:
com.idv_suite.api.workflows.operation_finished.v1Quando é enviado: ao encerrar a operação (sucesso, rejeição, expiração ou erro).
Para que serve: definir a decisão final e encerrar o processo de negócio.
Tipagem TypeScript:
Exemplo:
Atualizado