Pular para o conteúdo principal

Visão geral

O relatório de prova de vida registra tudo o que a Didit observou ao verificar que havia uma pessoa real e viva diante da câmera, e não uma foto impressa, uma reprodução de tela ou um deepfake. Ele inclui o método de prova de vida, uma pontuação de confiança de 0 a 100, a selfie de referência e o vídeo da captura, uma estimativa de idade opcional, métricas de qualidade da prova de vida passiva e correspondências faciais entre sessões em relação ao histórico e à lista de bloqueio da sua aplicação. O relatório é gerado depois que o usuário conclui a etapa de prova de vida em um fluxo de verificação (workflow) ou chama o endpoint facial independente. A Didit executa um dos três métodos de prova de vida (3D ativo, flashing ou passivo), atribui uma pontuação à captura, procura padrões de spoofing conhecidos e compara biometricamente o rosto com todos os outros rostos já vistos na sua aplicação. Cada relatório tem seu próprio status, independente do status geral da sessão, que reflete apenas o resultado da etapa de prova de vida:
  • Aprovado: rosto detectado, pontuação de prova de vida acima do limiar de revisão e nenhum aviso de recusa automática disparado.
  • Em Revisão: um ou mais avisos encaminhados para revisão foram disparados, ou a pontuação está igual ou abaixo do limiar de revisão, mas acima do limiar de recusa.
  • Recusado: uma condição de recusa automática foi disparada (NO_FACE_DETECTED, LIVENESS_FACE_ATTACK, FACE_IN_BLOCKLIST ou os riscos de idade em fluxos de estimativa de idade), um aviso configurável encaminhado para recusa foi disparado, ou a pontuação está igual ou abaixo do limiar de recusa.
  • Não concluído: o usuário nunca concluiu a etapa de prova de vida.

Onde aparece nas respostas da API

O relatório de prova de vida aparece como liveness_checks[] em GET /v3/session/{sessionId}/decision/. É sempre um array JSON, nunca um objeto liveness singular. Várias entradas aparecem quando um fluxo executa a prova de vida mais de uma vez (por exemplo, uma verificação principal mais uma nova captura).
  • API de decisão da sessão: GET /v3/session/{sessionId}/decision/ retorna liveness_checks[] no nível superior. Consulte Obter a decisão da sessão.
  • Webhooks: os payloads de session.status.updated incluem o mesmo array liveness_checks[] assim que a etapa gera dados. Consulte Webhooks.
  • API independente de prova de vida: consulte API independente de prova de vida.
Leia response.liveness_checks[0] e percorra o array. O formato singular liveness citado em alguns tutoriais antigos não existe no endpoint de decisão v3.

Schema

O schema canônico, campo a campo, está na página de referência Modelos de dados. Os campos abaixo espelham esse schema canônico.

Correspondências faciais entre sessões

matches[] lista os rostos do histórico da sua aplicação que ultrapassaram o limiar de similaridade biométrica em relação a esta selfie: até 5 itens, primeiro os rostos na lista de bloqueio e na lista de permissões, depois em ordem decrescente de similaridade. São candidatos elegíveis os rostos na lista de bloqueio, os rostos na lista de permissões, os rostos de sessões Approved e os rostos importados para os seus usuários do fornecedor (vendor users). Os rostos que pertencem ao mesmo usuário (mesmo vendor_data ou, quando disponível, o mesmo usuário do fornecedor) são excluídos de toda a busca: tanto da detecção de duplicatas quanto da verificação na lista de bloqueio. Cada item inclui:

Valores de status

Os status vêm do enum compartilhado de status de recursos (FeatureStatusChoices).

Exemplos

Approved: captura 3D ativa sem problemas

In Review: prova de vida passiva, captura de baixa qualidade e possível duplicata

Aqui, a qualidade facial (12.4) está abaixo do limiar de revisão padrão (15), a luminância (18.7) está abaixo do mínimo padrão (20) e a ação do fluxo de trabalho para faces duplicadas está definida como Review; por isso, os três avisos têm log_type: "warning" e o relatório é definido como In Review.

Nota de segurança

Vídeos e selfies de prova de vida são dados biométricos: as URLs assinadas são temporárias e expiram (após 4 horas, por padrão). Considere-as de curta duração: não as armazene em cache nem as exponha publicamente. Normalmente, sua aplicação precisa apenas de status, score e dos avisos; armazene o mínimo possível para reduzir os dados biométricos nos seus servidores.

Relacionados

Última modificação em 1 de novembro de 2026