Pular para o conteúdo principal

Visão geral

O relatório de verificação de identidade reúne tudo o que a Didit extraiu e validou de um documento de identidade emitido pelo governo: passaportes, carteiras de identidade, carteiras de motorista e autorizações de residência. Ele agrupa os campos biográficos e do documento obtidos por OCR, URLs assinadas para as mídias capturadas, dados de endereço interpretados e geolocalizados, pontuações de qualidade de imagem de cada lado do documento, o conteúdo da MRZ, detalhamentos por sistema de escrita (latino / não latino) e correspondências de documentos entre sessões. O relatório é gerado depois que o usuário conclui a etapa de captura do documento em um fluxo de verificação (workflow) ou chama o endpoint de OCR independente. A Didit identifica o tipo de documento, executa o OCR, valida a MRZ, o código de barras ou o QR code, interpreta o endereço, verifica sinais de adulteração (captura de tela, cópia impressa, manipulação do retrato) e compara o documento com todos os outros documentos capturados na sua aplicação. Cada relatório tem seu próprio status, independente do status geral da sessão, que reflete como a etapa de identidade foi resolvida isoladamente:
  • Aprovado: documento reconhecido, todos os campos obrigatórios extraídos e nenhum aviso direcionado à recusa foi disparado.
  • Em Revisão: um ou mais avisos foram disparados e o seu fluxo os direciona para revisão.
  • Recusado: uma condição de recusa automática foi disparada (documento não suportado, documento expirado, retrato ausente, ocorrência na lista de bloqueio, falha na verificação adaptativa de idade) ou foi disparado um aviso cuja ação configurada é Decline (as condições de idade mínima/máxima usam Decline por padrão).
  • Expirado: a expiration_date do documento venceu após a verificação. O monitoramento contínuo de validade da Didit muda o relatório de Approved para Expired, adiciona um aviso DOCUMENT_EXPIRED e move uma sessão aprovada para o status de sessão Kyc Expired.
  • Não concluído: o usuário nunca concluiu a etapa de captura.

Onde ele aparece nas respostas da API

O relatório de identidade é entregue dentro do array id_verifications[], que é sempre um array JSON e nunca um objeto id_verification singular. Aparecem várias entradas quando um fluxo executa mais de uma etapa de documento (por exemplo, um documento de identidade principal mais uma verificação adicional).
  • API de decisão da sessão: GET /v3/session/{sessionId}/decision/ retorna id_verifications[] no nível superior. Consulte Obter a decisão da sessão.
  • Webhooks: os payloads de session.status.updated incluem o mesmo array id_verifications[] assim que a etapa tiver gerado dados. Consulte Webhooks.
  • API de OCR independente: o envio direto de documentos retorna um objeto id_verification singular com os mesmos campos. Consulte API de OCR independente.
Leia response.id_verifications[0] e percorra o array. A estrutura individual de id_verification existe apenas na API de OCR independente e não existe no endpoint de decisão v3.

Esquema

O esquema canônico, campo a campo, está na página de referência Modelos de dados. Os campos abaixo vêm diretamente de IDVerificationV3Serializer, que estende IDVerificationV2Serializer e adiciona node_id, o array matches[] de correspondências entre sessões e o array document_selfie_face_matches[] do Silent Capture.

Campos de nível superior

issuing_state é sempre de nível nacional, nunca subnacional. Para todo tipo de documento, incluindo carteiras de motorista emitidas por um estado ou província (Austrália, Estados Unidos, Canadá), issuing_state e issuing_state_name informam o país (por exemplo AUS / Australia), e não o estado. O valor subnacional, quando o documento o contém, fica disponível separadamente em parsed_address.region (com extra_fields.state como alternativa em alguns tipos de documento). A visão geral da sessão no Business Console exibe esse valor como uma linha Region abaixo de Issuing state, quando presente.
Carteiras de motorista com dois números (Austrália). As carteiras australianas trazem impressos tanto um número da licença, que identifica a habilitação do titular para dirigir e permanece o mesmo quando o cartão é substituído, quanto um número do cartão, que identifica o cartão físico e muda a cada nova emissão. Para essas carteiras, a Didit sempre mapeia os números da mesma forma:
  • personal_number — o número da licença
  • document_number — o número do cartão
Isso se aplica a todos os estados e territórios australianos (NSW, VIC, QLD, WA, SA, TAS, ACT, NT). Em algumas variantes, o número do cartão está impresso apenas no verso, então ele só é lido quando o verso da carteira é capturado. Quando nenhum número do cartão pode ser lido, o número da licença é informado tanto em document_number quanto em personal_number, de modo que document_number sempre contém um identificador quando a verificação é concluída. personal_number é o número da licença em ambos os casos. Em outros tipos de documento, document_number continua sendo o número principal extraído por OCR e pode ser, ele próprio, um identificador do titular.
O CUIL argentino é extra_fields.tax_number, nunca personal_number. Os documentos argentinos imprimem o CUIL (o identificador de 11 dígitos usado como chave pela AFIP, pela ANSES e pelos birôs de crédito) em um lugar diferente em cada documento, e o DNI imprime um segundo número de 11 dígitos ao lado dele:
  • na carteira de motorista, o CUIL é o que personal_number contém;
  • no DNI, personal_number contém o número de trámite, que identifica a solicitação do cartão e não é um identificador do titular. O CUIL do DNI é lido no próprio campo impresso.
Portanto, personal_number não é um CUIL confiável para a Argentina: em um DNI, ele é um número de 11 dígitos que, silenciosamente, não retornará nenhum resultado em nenhum registro. Leia extra_fields.tax_number em vez disso. A Didit só o informa quando o valor é validado como um CUIL real (prefixo de pessoa mais o dígito verificador módulo 11), em dígitos canônicos sem separadores (27111111117), qualquer que seja o documento argentino apresentado pelo titular. Quando o CUIL do cartão não pôde ser lido, a chave fica ausente em vez de ser preenchida com um número que não é um CUIL. Para atender esses usuários, capture a carteira de motorista como segundo documento ou colete o CUIL por meio de uma resposta de Questionário ou do metadata da sessão.

Pontuações de qualidade da imagem

front_image_quality_score e back_image_quality_score retornam, cada um:
Use overall_score como uma verificação rápida de adequação: pontuações acima de 70 geralmente indicam uma captura boa o suficiente para uma verificação confiável.

Pontuações de prova de vida do documento

document_liveness informa o que a verificação de prova de vida do documento mediu, tenha ela gerado um aviso ou não. Um aviso só existe quando uma pontuação ficou abaixo de um dos limiares do fluxo; por isso, antes deste campo, um documento aprovado não trazia nenhuma evidência de prova de vida. É com este campo que você audita uma sessão aprovada. Ele é null quando a verificação não foi executada (por exemplo, em um método que não é de documento ou em uma indisponibilidade do modelo registrada nos logs da sessão). Ele contém um objeto por tipo de fraude (portrait_replace, printed_copy e screen_replay), cada um com:
Para documentos mais antigos sem evidência de avaliação salva, as pontuações armazenadas continuam visíveis, mas ambos os limiares e bucket são null. As configurações atuais do fluxo nunca são usadas para reconstruir um resultado histórico. O mesmo se aplica a uma captura cuja avaliação do documento ainda não foi concluída. O Business Console mostra as mesmas três linhas no bloco Document liveness da seção de Verificação de identidade da sessão.

Correspondências entre sessões

matches[] lista até 5 outros documentos na sua aplicação que correspondem a este: mesma data de nascimento, mesmo país emissor e um nome completo muito semelhante. Documentos na lista de bloqueio exigem, além disso, uma correspondência exata do número do documento. Sessões que pertencem ao mesmo usuário (mesmo vendor_data) são excluídas. Cada entrada inclui session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted (true quando o documento foi adicionado à sua lista de bloqueio), api_service e uma front_image_url assinada.

Valores de status

Documentos com múltiplos sistemas de escrita (latino / não latino)

Alguns documentos, como os do Quirguistão, Cazaquistão, Rússia, Japão, Coreia, China, países árabes, Tailândia e outros, imprimem o nome, o endereço ou o local de nascimento do titular tanto em uma transliteração latina quanto no sistema de escrita local. Você escolhe qual sistema de escrita preenche os campos de nível superior com a configuração preferred_characters do fluxo (ou da API independente): Os valores no sistema de escrita alternativo ficam dentro de extra_fields, em chaves com sufixo: first_name_non_latin, last_name_non_latin, middle_name_non_latin, full_name_non_latin, address_non_latin, place_of_birth_non_latin (ou as variantes _latin correspondentes).

Quando os campos de sistema de escrita alternativo aparecem

  • Somente quando os dois sistemas de escrita estão realmente presentes no documento. Se um campo de OCR nominalmente rotulado como “Surname-Kyrgyz (Cyrillic)” for extraído como texto em escrita latina (homóglifos ou uma transliteração latina), ele não se qualifica como alternativa não latina e essa chave é omitida.
  • full_name_non_latin (e full_name_latin) são sempre reconstruídos a partir dos componentes individuais de nome, nome do meio e sobrenome quando ambos os sistemas de escrita estão disponíveis. O campo bruto “Full Name” do OCR é ignorado por questão de consistência.
  • Quando preferred_characters=latin, mas o documento contém apenas texto não latino (de modo que os campos de nível superior acabam ficando em sistema de escrita não latino), a Didit executa uma etapa de transliteração e expõe first_name_latin, last_name_latin, middle_name_latin, full_name_latin, place_of_birth_latin e address_latin como alternativa em escrita latina.
last_name_non_latin está ausente porque, nesta amostra, o campo “Surname (Cyrillic)” do documento retornou em caracteres latinos: não havia um sobrenome genuinamente não latino para extrair.

Exemplos

Approved: documento de identidade espanhol sem problemas (todos os campos)

In Review: QR não detectado em um documento que deveria ter um

Resumido: uma resposta real sempre traz o conjunto completo de campos mostrado acima.

Nota de segurança

As URLs assinadas retornadas para imagens e vídeos de documentos são temporárias: elas expiram após um período de validade limitado. Trate-as como de curta duração: baixe o que precisar imediatamente e não as armazene em cache nem as exponha publicamente. Normalmente, sua aplicação só precisa de status, de alguns campos biográficos e dos avisos. Armazene o mínimo possível para reduzir a superfície de exposição em caso de futura violação.

Relacionados

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