# Como ler um resultado de verificação

Source: https://help.didit.me/pt-BR/verification-sessions/reading-a-verification-result
Updated: 2026-10-12

O resultado de uma sessão é um status, mais um resultado por verificação, mais uma lista de avisos - os avisos são a parte que te diz o que realmente aconteceu.

Leia nesta ordem: o **status geral**, depois os **status por verificação**,
depois os **avisos**. Os avisos são a única parte que te diz *por quê* -
todo o resto só te diz *o quê*.

[Video: Como ler um resultado de verificação - Didit Academy](https://www.youtube.com/watch?v=7htTWCWsl60)

Abra qualquer sessão em **Verifications** no [Business Console](https://business.didit.me) e você vê as mesmas três camadas, seja no console, em um payload de webhook, ou em uma resposta de API.

![Detalhe da sessão no console da Didit com o veredito geral, os resultados por verificação e os dados extraídos](https://help.didit.me/screenshots/session-detail-light.webp)

*Uma sessão, três camadas: status geral, resultados por verificação, e os avisos por trás deles.*

## Camada 1 - o status geral

O veredito único da sessão: Approved, Declined, In Review, e assim por diante. É nisso que a maioria das integrações age. É um agregado: vem da combinação do resultado de cada verificação, conforme a configuração do seu workflow, então ele nunca te diz sozinho qual verificação foi responsável.

## Camada 2 - um resultado por verificação

Cada verificação executada tem seu próprio status e seus próprios dados. As que você vai ver com mais frequência:

| Verificação | O que observar |
|---|---|
| **Verificação de ID** | Campos extraídos (nome, número do documento, datas), tipo e país do documento, e se o MRZ validou |
| **Prova de vida passiva / ativa** | Se um humano vivo foi detectado, e qualquer sinal de ataque |
| **Reconhecimento facial 1:1** | A pontuação de similaridade entre a selfie e a foto do documento |
| **Busca facial 1:N** | Se esse rosto corresponde a um usuário já verificado ou a uma entrada da blocklist |
| **Triagem AML** | As ocorrências, cada uma com uma pontuação de correspondência e uma pontuação de risco |
| **Análise de dispositivo e IP** | País, sinais de VPN ou proxy, endereços na blocklist |
| **Comprovante de endereço** | O endereço extraído e o quanto ele correspondeu ao que você informou |
| **NFC** | Se o chip foi lido e se a assinatura dele encadeou até um emissor confiável |
| **Telefone / e-mail** | Se o OTP foi confirmado, além de sinais de risco no número ou no endereço |

Uma verificação pode estar Approved enquanto a sessão está Declined, e vice-versa. Isso é normal - o status da sessão é a combinação, não o pior caso.

## Camada 3 - os avisos

Os avisos são a camada que realmente explica o resultado. Cada um é um código específico e nomeado, associado à verificação que o gerou - por exemplo:

- `DOCUMENT_EXPIRED` - a data de validade do documento já passou.
- `MRZ_VALIDATION_FAILED` - o checksum da zona de leitura mecânica não fechou. Um forte sinal de adulteração.
- `LOW_FACE_MATCH_SIMILARITY` - a selfie e a foto do documento pontuaram abaixo do seu limiar.
- `LIVENESS_FACE_ATTACK` - um ataque de apresentação foi detectado durante a selfie.
- `POSSIBLE_MATCH_FOUND` - o AML encontrou uma ocorrência candidata que precisa ser resolvida.
- `NFC_DATA_DOES_NOT_MATCH_OCR` - o chip e os dados impressos divergem.
- `IP_ADDRESS_IN_BLOCKLIST` - a conexão veio de um endereço que você bloqueia.

> **Tip:** Quando você está depurando uma sessão específica, vá direto para os avisos. O
> status te dá a conclusão; os avisos te dão a evidência. Todo catálogo de avisos
> por funcionalidade está documentado em
> [core technology](https://docs.didit.me/core-technology/id-verification/warnings-id-verification).

## Dados extraídos vs. o que você esperava

Se você enviou `expected_details` ao criar a sessão - um nome, uma data de nascimento, um número de documento que você já tinha - o resultado também te diz se o documento concordou com isso. Uma divergência aí costuma ser um problema de digitação do seu lado, e não um documento fraudulento, então vale a pena checar antes de reprovar alguém.

> **Warning:** Nomes extraídos podem estar transliterados. Um documento em cirílico, árabe, ou grego
> gera um nome em script latino que pode não bater com os seus registros
> caractere por caractere, mesmo sendo a mesma pessoa. Compare também pelo número do
> documento ou pela data de nascimento antes de tratar uma divergência de nome como
> fraude.

## Resultados de sandbox parecem um pouco diferentes

Em uma sessão de sandbox, o console marca as seções de dados extraídos com um chip de **Simulated data**. A mídia foi capturada de verdade, mas os campos e o resultado vieram do cenário que você escolheu - então não tire conclusões dos valores em si. Veja [testar no sandbox](https://help.didit.me/pt-BR/getting-started/sandbox-and-testing).

## Obtendo a mesma coisa de forma programática

O payload do webhook e o `GET /v3/session/{id}/decision/` trazem as três camadas em um único objeto `decision`. Trate o webhook como sua fonte da verdade e use o polling apenas para reconciliação - alguns eventos, como edições de dados feitas por um revisor, só chegam por webhook. Veja [obtendo resultados com webhooks](https://help.didit.me/pt-BR/integration/webhooks-basics).

## Obtendo uma cópia para seus registros

Para auditorias e registros regulatórios, baixe a sessão como PDF - ele reúne todas as etapas, os dados extraídos, as pontuações biométricas, os resultados de AML, e a decisão final. Veja [baixando um relatório de verificação](https://help.didit.me/pt-BR/verification-sessions/download-verification-report).