For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

  1. Você configura uma URL HTTPS de recepção na sua integração.

  2. O sistema envia eventos por POST com payload JSON.

  3. Somente os eventos aos quais você se inscreveu na sua configuração são enviados.

  4. Cada mensagem inclui assinatura para validar a autenticidade.

Recomendação para seu Endpoint:

  • responder rapidamente com 2xx quando a mensagem for aceita,

  • processar de forma assíncrona quando possível,

  • lidar com idempotência usando id do 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 signature dentro 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 interpretar data).

  • 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:

  • specversion hoje é sempre "1.0".

  • id, time e signature não têm catálogo fechado.

  • source sempre 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.v1

  • Quando é 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.v1

  • Quando é 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.v1

  • Quando é 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:

  • data e summary não têm um schema fechado na implementação atual.

  • assets contém IDs de assets associados ao evento.

Exemplo:

4) Selfie capturada

  • Tipo: com.idv_suite.api.workflows.selfie_captured.v1

  • Quando é 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.v1

  • Quando é enviado: quando houver leitura NFC do documento.

  • Para que serve: enriquecer e contrastar informações documentais.

Tipagem TypeScript:

Notas:

  • Assim como em id_captured, data e summary continuam abertos.

Exemplo:

6) Liveness Passivo avaliado

  • Tipo: com.idv_suite.api.workflows.passive_liveness_evaluated.v1

  • Quando é enviado: após avaliar teste de vida passivo.

  • Para que serve: detectar possíveis tentativas de suplantação.

Tipagem TypeScript:

Notas:

  • diagnostic nã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.v1

  • Quando é 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.v1

  • Quando é enviado: ao comparar o rosto do documento com a selfie.

  • Para que serve: validar correspondência biométrica.

Tipagem TypeScript:

Notas:

  • authStatus não tem enum fechado no código. O exemplo conhecido é "Positive".

Exemplo:

9) Cadastro facial

  • Tipo: com.idv_suite.api.workflows.facial_enrollment.v1

  • Quando é 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.v1

  • Quando é enviado: ao validar a identidade contra um cadastro anterior.

  • Para que serve: autenticação ou confirmação de identidade.

Tipagem TypeScript:

Notas:

  • authStatus permanece aberto; o exemplo conhecido é "Positive".

  • assets neste evento é emitido como string simples, não como string[].

Exemplo:

11) Matching documental avaliado

  • Tipo: com.idv_suite.api.workflows.document_matching_evaluated.v1

  • Quando é 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.v1

  • Quando é 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