Extração de dados
Uma API de OCR para leitura de documentos de identidade que retorna campos estruturados, não um bloco de texto.
O ShieldID transforma um documento de identidade com foto emitido pelo governo em dados estruturados, campo a campo: nome, data de nascimento, número do documento, validade, endereço e mais, cada um com sua origem e seu próprio veredicto. Uma API de extração de dados de documentos e uma API de verificação de documentos na mesma sessão.
O que é retornado
Campos estruturados, onde o documento realmente os traz.
Nem todo documento traz todos os campos. O ShieldID retorna o que o documento tem e indica o que ele não tem.
- Nome completo
- Conforme impresso e conforme codificado no código de barras ou na MRZ, quando o documento traz um deles.
- Data de nascimento
- Lido da face impressa e verificado em cruzamento com o código de barras e a MRZ.
- Número do documento
- Número da carteira ou do passaporte, verificado quanto à consistência interna quando o formato do emissor permitir.
- Data de validade
- Lido da face impressa e do código de barras ou da MRZ.
- Endereço
- Lido da face impressa e do código de barras, quando presente; comparável com um documento de endereço enviado separadamente.
- Sexo
- Lido quando o documento o imprime ou o codifica.
- Jurisdição emissora
- Identificado a partir do código do emissor no código de barras, quando o documento traz um código reconhecido, conforme disponível.
Três fontes, uma comparação
Código de barras, MRZ e a frente impressa, lidos de propósito, não misturados por acidente.
Cada campo é atribuído à fonte de onde veio. Quando duas fontes divergem, isso vira um alerta no resultado, e não uma média dos dois números.
Código de barras PDF417
O verso de uma carteira de motorista ou de um documento de identidade norte-americano é decodificado em campos AAMVA estruturados. Quando um documento possui código de barras, os campos dele têm prioridade sobre a frente impressa.
MRZ do passaporte
A zona de leitura óptica é localizada, lida e validada com as fórmulas de dígito verificador da ICAO embutidas na própria zona. Uma pontuação mínima de validade, conferida em relação a essa pontuação, determina se um campo lido pela MRZ é considerado confiável — uma zona que falha no próprio checksum não pode se sobrepor a uma fonte mais limpa.
OCR estruturado e de página inteira da frente
A face impressa é lida usando o layout do próprio documento, quando ele é reconhecido, recorrendo ao OCR de página inteira para que um documento desconhecido ainda gere campos legíveis.
Conflitos são sinalizados, não calculados em média
Um nome ou data de nascimento que diverge entre a frente, o código de barras e a MRZ é informado como inconsistência no resultado. Nada no pipeline escolhe um vencedor em silêncio e esconde a divergência.
Validação de checksum da MRZ
Uma zona de leitura óptica precisa conferir a própria matemática antes de confiarmos nela.
A zona de leitura óptica da ICAO em um passaporte traz dígitos verificadores por design. O ShieldID os valida antes de tratar um campo lido pela MRZ como confiável.
Um detector dedicado localiza a MRZ, um leitor extrai os caracteres e o resultado recebe uma pontuação de validade com base nas fórmulas de checksum da própria zona. Somente um campo que atinge a pontuação mínima de validade é considerado com prioridade total; uma zona com leitura ruim é tratada como tal, em vez de ser repassada como se estivesse limpa.
Prioridade ao código de barras
Quando as fontes se sobrepõem, a mais confiável prevalece.
O mesmo campo pode aparecer no código de barras, na MRZ e na frente impressa. O ShieldID resolve isso com uma única ordem consistente, sempre.
- Código de barras PDF417
- MRZ do passaporte, depois de passar no checksum
- Leitura estruturada da frente impressa
- Fallback de OCR de página inteira
Comprovantes de endereço
Envie um segundo documento e receba uma comparação de endereço direta.
Quando uma verificação exige comprovante de endereço, o solicitante envia um documento separado e o ShieldID o lê da mesma forma que lê o documento de identidade.
O comprovante de endereço passa por OCR, e o endereço dele é comparado com o endereço lido do documento de identidade. É uma comparação simples de texto e tokens, não um classificador de documentos à parte, e só é executada quando a sessão exige e um documento foi realmente enviado.
Redação e tratamento de PII
Os dados extraídos são protegidos da mesma forma que as imagens.
Os campos estruturados ficam sob os mesmos controles de privacidade que se aplicam às próprias fotos do documento.
Data de nascimento criptografada em repouso
A data de nascimento é armazenada criptografada em repouso; o serviço não funciona sem a chave de criptografia configurada.
Imagens descartadas por temporizador
As imagens do documento e da selfie capturadas são descartadas automaticamente em um prazo curto, de sete dias por padrão. Uma varredura é executada em intervalos e novamente logo após cada reinicialização, para que um período de inatividade nunca deixe uma imagem armazenada além do dia em que deveria ter sido removida.
Ocultação de pontuações no dispositivo
Quando uma pontuação de correspondência ou de confiança seria exibida no próprio celular do solicitante, o ShieldID remove a porcentagem subjacente da mensagem antes de exibi-la, para que uma pontuação bruta nunca apareça fora da sua conta.
O registro dura mais que as imagens
As imagens seguem um cronograma. O fato de que uma verificação aconteceu, e o que ela encontrou, permanece na sua conta — e, em uma integração com o Trust Ledger, como um registro de verificado/reprovado no Activity Ledger (registros de ledger para contas da API do ShieldID: em breve).
Resultado de exemplo
Veredictos por campo, no formato que a API retorna.
Nomes, números e endereços abaixo são fictícios, criados para este exemplo. O conjunto de campos, a origem e os veredictos têm o formato real de um resultado.
| Campo | Valor | Origem | Veredicto |
|---|---|---|---|
| person.name | "Maria Gonzalez" | barcode | match |
| person.dob | "1991-07-22" | barcode | match |
| person.document_number | "D1234567" | barcode | match |
| person.document_country | "US" | barcode issuer code | match |
| person.address | "1428 Elm St, Sacramento, CA" | barcode | match |
| identity.name_match | PASS | front vs barcode vs requester | PASS |
| checks.document_tamper | "no_indication" | advisory model | advisory, not gating |
// Sample result. Names, numbers and addresses are fictional.
{
"session_id": "ses_9f2c...sample",
"status": "VERIFIED",
"environment": "sandbox",
"person": {
"name": "Maria Gonzalez",
"dob": "1991-07-22",
"document_type": "DRIVERS_LICENCE",
"document_country": "US",
"document_jurisdiction": "CA",
"address": "1428 Elm St, Sacramento, CA"
},
"identity": {
"checks": ["name_match"],
"warnings": [],
"sources": {
"name": "barcode",
"dob": "barcode",
"address": "barcode"
}
},
"checks": {
"document": "PASS",
"identity": "PASS",
"document_tamper": "no_indication"
},
"completed_at": "2026-09-17T14:02:11Z"
}Notas de integração
Os mesmos campos, onde quer que você leia o resultado.
Os campos estruturados não são um produto separado da sessão de verificação. Eles chegam como parte do mesmo resultado.
- Os campos são entregues no resultado da sessão que você consulta pela API assim que uma verificação é concluída.
- O mesmo resultado é entregue ao seu endpoint por um webhook assinado quando a verificação termina, para que você não precise ficar consultando.
- Cada campo é atribuído à sua origem e traz seu próprio veredicto, tanto no resultado da API quanto no payload do webhook.
- As sessões sandbox retornam o mesmo formato de campos que a produção, para que você construa sua integração antes de ler um único documento real.
Perguntas
Respostas diretas sobre extração de dados.
Veja os campos com os próprios olhos
Execute uma verificação sandbox e leia o resultado estruturado.
Crie uma sessão sandbox, escaneie um documento no seu próprio celular e veja cada campo, sua origem e seu veredicto na resposta. As sessões sandbox nunca são cobradas.