Saltar para o conteúdo principal

Visão geral

A verificação de comprovativo de morada (POA) aceita um único PDF ou imagem (TIFF, JPG, JPEG, PNG, WEBP, opcionalmente comprimido em ZIP) até 15 MB, executa a classificação do tipo de documento, extração baseada em LLM e análise forense de PDF/EXIF, e devolve:
  • A morada extraída — tanto em formato bruto como estruturado (street_1, city, region, postal_code, lat/lng).
  • Metadados do documento — tamanho do ficheiro, tipo de conteúdo, datas de criação e modificação, datas EXIF, informações de assinatura e quaisquer indícios de manipulação de sobreposições detetados pela análise forense de PDF.
  • Pontuações de correspondência de nome em relação ao documento de identificação verificado e aos detalhes esperados fornecidos na criação da sessão.
  • Campos adicionais bancários (número de conta, IBAN, sort code, routing number, SWIFT/BIC, agência) quando o documento é um extrato bancário.
Captura de ecrã do relatório de comprovativo de morada da Didit mostrando campos de morada extraídos e tipo de documento
A extração de POA realiza a leitura de texto não estruturado, o que introduz uma latência de 5–15 segundos por documento. Os webhooks só são acionados quando todo o passo do fluxo de verificação é concluído — não faça pedidos repetidos (polling) ao endpoint de decisão mais frequentemente do que uma vez a cada 5 s durante este intervalo.

Onde aparece nas respostas da API

O endpoint de decisão devolve o POA como o array plural poa_verifications[] em GET /v3/session/{sessionId}/decision/. Cada entrada corresponde a uma execução do nó de POA no seu fluxo; sessões com múltiplos passos de POA (por exemplo, extrato bancário + fatura de serviços públicos) produzem uma entrada por execução com o seu próprio node_id.
A estrutura abaixo reflete o esquema canónico — consulte Modelos de dados.

Esquema

Consulte Comprovativo de morada na referência de modelos de dados para o esquema canónico.
Cada entrada em warnings[] é um objeto de aviso: { feature, risk, additional_data, log_type, short_description, long_description, node_id }, com feature sempre "PROOF_OF_ADDRESS" para este relatório.

Valores de estado

O campo status utiliza o enum de estado ao nível da funcionalidade (FeatureStatusChoices). Regras de estado personalizadas configuradas no nó do fluxo podem ajustar ainda mais o estado calculado; as regras são combinadas segundo a precedência Declined > In Review > Approved. Consulte Avisos de comprovativo de morada para o mapeamento completo de risco para ação, incluindo o comportamento de nova tentativa exclusivo do fluxo para FUTURE_ISSUE_DATE.

Evidência de manipulação por sobreposição em PDF

Quando o documento enviado é um PDF, document_metadata.overlay_manipulation pode conter evidência forense de sobreposições de texto suspeitas:
  • detected: true quando a verificação encontrou evidência de manipulação.
  • analyzed: true quando o PDF pôde ser analisado.
  • analysis_incomplete: presente e true apenas quando o ficheiro não pôde ser verificado na totalidade. O que foi verificado mantém os respetivos resultados sempre que possível, e o documento apresenta POA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT.
  • signals: as verificações que dispararam (duplicate_font_subset, glyph_fragmentation).
  • manipulated_regions: retângulos, em coordenadas da página, em torno do texto suspeito de ter sido editado. Cada retângulo usa o espaço de coordenadas da página do PDF (x, y, width, height, page_width, page_height), para que os revisores possam destacar a área afetada numa pré-visualização do PDF.
O campo é null quando o documento não é um PDF ou quando o PDF não pôde ser analisado. Quando detected=true, o sistema também emite um aviso SUSPECTED_DOCUMENT_MANIPULATION, cujo additional_data replica os sinais e os retângulos acima (exceto quando um sinal mais forte, a modificação após a assinatura digital, com is_tampered=true, tem prioridade; nesse caso, o additional_data descreve a adulteração da assinatura).

Códigos QR e códigos de barras

Cada relatório de POA inclui detected_codes, cobrindo todas as páginas processadas. Cada item contém: O campo detected_codes é um array vazio quando não é encontrado nenhum código suportado. A Didit nunca adivinha um payload: códigos danificados ou ilegíveis podem ser devolvidos com a sua localização e parsed_payload: null, enquanto falhas na deteção de códigos não reprovam a verificação de POA.

Exemplos

Aprovado — extrato bancário

Recusado — manipulação de sobreposição + divergência de nome

Relacionados

document_file e extra_files[] são URLs pré-assinados que expiram após cerca de 4 horas. Chame novamente o endpoint de decisão para atualizar os URLs. Armazene apenas o estado de verificação e os campos de morada analisados do seu lado — minimize os dados de documentos conservados.
Última modificação em 7 de novembro de 2026