Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesVisão geral
O relatório de verificação de identidade regista tudo o que a Didit extraiu e validou a partir de um documento de identificação oficial — passaportes, cartões de cidadão, cartas de condução e autorizações de residência. Agrupa os campos biográficos e do documento extraídos por OCR, URLs assinados para o conteúdo multimédia capturado, dados de morada processados e geolocalizados, pontuações de qualidade de imagem por lado, conteúdos da MRZ, discriminação por sistema de escrita (latino / não latino) e correspondências de documentos entre sessões. O relatório é gerado após o utilizador concluir o passo de captura de documentos num fluxo (ou chamar o endpoint de OCR autónomo). A Didit identifica o tipo de documento, executa o OCR, valida a MRZ / código de barras / código QR, processa a morada, analisa sinais de adulteração (captura de ecrã, cópia impressa, manipulação de retrato) e compara o documento com todos os outros documentos capturados na sua aplicação. Cada relatório possui o seu própriostatus — independente do estado geral da sessão — que reflete como o passo de identificação foi resolvido de forma isolada:
- Aprovada — documento reconhecido, todos os campos obrigatórios extraídos, nenhum aviso com encaminhamento de recusa acionado.
- Em análise — um ou mais avisos foram acionados e o seu fluxo encaminha-os para revisão.
- Recusada — uma condição de recusa automática foi acionada (documento não suportado, documento expirado, retrato em falta, correspondência na lista de bloqueio, falha na idade adaptativa) ou foi acionado um aviso cuja ação configurada é Recusar (idades mínima/máxima predefinidas como Recusar).
- Expirada — a
expiration_datedo documento foi ultrapassada após a verificação. A monitorização contínua de expiração da Didit altera o relatório deApprovedparaExpired, anexa um avisoDOCUMENT_EXPIREDe move uma sessão aprovada para o estado de sessãoKyc Expired. - Não Concluído — o utilizador nunca concluiu o passo de captura.
Onde aparece nas respostas da API
O relatório de verificação de identidade é fornecido dentro do arrayid_verifications[] — sempre um array JSON, nunca um objeto id_verification singular. Surgem múltiplas entradas quando um fluxo executa mais do que um passo de documento (por exemplo, uma identificação principal mais um reforço de verificação).
- API de decisão de sessão —
GET /v3/session/{sessionId}/decision/devolveid_verifications[]no nível superior. Consulte Obter decisão da sessão. - Webhooks — os payloads de
session.status.updatedincluem o mesmo arrayid_verifications[]assim que o passo gerar dados. Consulte Webhooks. - API de OCR autónomo — a submissão direta de documentos devolve um objeto singular
id_verificationcom os mesmos campos. Consulte API de OCR autónomo.
Leia
response.id_verifications[0] e itere o array. A estrutura singular id_verification apenas existe na API de OCR autónomo — não existe no endpoint de decisão v3.Schema
O esquema canónico campo a campo encontra-se na página de referência Modelos de dados. Os campos abaixo provêm diretamente doIDVerificationV3Serializer, que estende o IDVerificationV2Serializer e adiciona node_id, o array de correspondências entre sessões matches[] e o array document_selfie_face_matches[] do Silent Capture.
Campos de nível superior
issuing_state é sempre ao nível do país, nunca subnacional. Para todos
os tipos de documento, incluindo cartas de condução emitidas por um estado ou província
(Austrália, Estados Unidos, Canadá), issuing_state e
issuing_state_name indicam o país (por exemplo AUS /
Australia), e não o estado. O valor subnacional, quando o documento
apresenta um, está disponível separadamente em parsed_address.region (recorrendo
a extra_fields.state em alguns tipos de documento). A visão geral da sessão na Business
Console apresenta isto como uma linha de Região por baixo de
Estado emissor quando presente.Cartas de condução que incluem dois números (Austrália). As cartas de condução
australianas imprimem tanto um número de licença, que identifica a habilitação de
condução do titular e permanece inalterado quando o cartão é substituído, como um número de cartão,
que identifica o cartão físico e muda a cada nova emissão. Para estas
cartas de condução, a Didit mapeia sempre os números da mesma forma:
personal_number— o número da licençadocument_number— o número do cartão
document_number como personal_number, garantindo que document_number inclui sempre
um identificador assim que a verificação termina. personal_number é o
número da licença em qualquer dos casos. Noutros tipos de documento, document_number permanece
o número principal extraído por OCR e pode ser, por si só, um identificador ao nível do titular.O CUIL argentino é
extra_fields.tax_number, nunca personal_number.
Os documentos argentinos imprimem o CUIL — o identificador de 11 dígitos utilizado como chave pela AFIP, pela ANSES e
pelas agências de crédito — num local diferente em cada documento, e
o DNI imprime um segundo número de 11 dígitos ao lado deste:- na carta de condução, o CUIL é o valor de
personal_number; - no DNI,
personal_numbercontém o número de trámite, que identifica o pedido do cartão e não é um identificador do titular. O CUIL do DNI é lido a partir do seu próprio campo impresso.
personal_number não é um CUIL fiável para a Argentina: num DNI, é
um número de 11 dígitos que não devolverá qualquer resultado de nenhum registo, sem qualquer aviso.
Em vez disso, leia extra_fields.tax_number. O Didit apenas o comunica quando o valor
é validado como um CUIL real (prefixo da pessoa mais o dígito de controlo módulo-11), em
dígitos canónicos sem separadores (27111111117), qualquer que seja o documento argentino
apresentado pelo titular. Quando não foi possível ler o CUIL do cartão, a
chave fica ausente em vez de ser preenchida com um número que não é um CUIL — capture
a carta de condução como um segundo documento, ou recolha o CUIL através de uma
resposta num Questionário ou nos metadata da sessão, para cobrir esses utilizadores.Pontuações de qualidade da imagem
Tantofront_image_quality_score como back_image_quality_score devolvem:
Pontuações de prova de vida do documento
O campodocument_liveness comunica o que a verificação de prova de vida do documento mediu, quer tenha ou não gerado um aviso. Um aviso só existe quando uma pontuação fica abaixo de um dos limiares do fluxo, pelo que, antes deste campo, um documento aprovado não incluía qualquer evidência de prova de vida - o campo é a forma de auditar uma sessão aprovada. É null quando a verificação não foi executada (por exemplo, num método sem documento ou numa falha do modelo registada nos registos da sessão).
Contém um objeto por tipo de fraude - portrait_replace, printed_copy e screen_replay - cada um com:
bucket são null. As definições atuais do fluxo nunca são utilizadas para reconstruir um resultado histórico. O mesmo se aplica a uma captura cuja avaliação do documento ainda não tenha sido concluída.
A Business Console apresenta as mesmas três linhas no bloco Prova de vida do documento da secçã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 adicionalmente uma correspondência exata do número do documento. As sessões pertencentes ao mesmo utilizador (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 um front_image_url assinado.
Valores de estado
Documentos com múltiplos sistemas de escrita (latino / não latino)
Alguns documentos — quirguizes, cazaques, russos, japoneses, coreanos, chineses, árabes, tailandeses e outros — imprimem o nome, morada ou local de nascimento do titular tanto numa transliteração latina como no sistema de escrita local. Pode escolher qual o sistema de escrita que alimenta a resposta de nível superior com a definição do fluxo (ou da API autónoma)preferred_characters:
Os valores no sistema de escrita alternativo residem dentro de
extra_fields sob 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 surgem os campos no sistema de escrita alternativo
- Apenas quando ambos os sistemas de escrita estão realmente presentes no documento. Se um campo de OCR nominalmente etiquetado como “Surname-Kyrgyz (Cyrillic)” for extraído como texto em sistema de escrita latino (homóglifos ou uma transliteração latina), não é qualificado como uma alternativa não latina e essa chave é omitida.
full_name_non_latin(efull_name_latin) são sempre reconstruídos a partir dos componentes individuais de nome próprio, nome do meio e apelido quando ambos estão disponíveis — o campo bruto “Full Name” do OCR é ignorado por consistência.- Quando
preferred_characters=latinmas o documento contém apenas texto não latino (fazendo com que os campos de nível superior fiquem num sistema de escrita não latino), a Didit executa um passo de transliteração e disponibilizafirst_name_latin,last_name_latin,middle_name_latin,full_name_latin,place_of_birth_latineaddress_latincomo alternativa latina.
last_name_non_latin está ausente porque o campo “Surname (Cyrillic)” do documento foi retornado como carateres latinos nesta amostra — não existia um apelido não latino genuíno para extrair.
Exemplos
Approved — cartão de identificação espanhol sem irregularidades (todos os campos)
In Review — QR não detetado num documento que deveria ter um
Versão abreviada — uma resposta real inclui sempre o conjunto completo de campos apresentado acima.Nota de segurança
Os URLs assinados retornados para imagens e vídeos de documentos são temporários — expiram após uma janela de validade limitada. Trate-os como efémeros: transfira o que precisa prontamente e não os guarde em cache nem os exponha publicamente. Normalmente, a sua aplicação só precisa destatus, de alguns campos biográficos e dos avisos — armazene o mínimo possível para minimizar a superfície de ataque em caso de uma futura violação.
Relacionado
- Avisos de verificação de identidade — lista completa de avisos (enum), causas e remediação.
- Monitorização de documentos — como a Didit monitoriza adulterações e duplicados entre sessões.
- Documentos suportados — quais os tipos de documento e países abrangidos.
- Subtipos de documentos — lista completa de códigos de
document_subtype, incluindo a deteção de cartas de condução comerciais versus normais nos EUA. - Webhooks — escute
session.status.updatedpara receber o relatório. - Modelos de dados — Verificação de identidade — esquema canónico com todos os campos.