Saltar al contingut principal

Visió general

La verificació de comprovant de domicili (POA) accepta un únic PDF o imatge (TIFF, JPG, JPEG, PNG, WEBP, opcionalment comprimit en ZIP) de fins a 15 MB, executa la classificació del tipus de document, l’extracció basada en LLM i l’anàlisi forense de PDF/EXIF, i retorna:
  • L’adreça extreta: tant en format brut com estructurat (street_1, city, region, postal_code, lat/lng).
  • Metadades del document: mida del fitxer, tipus de contingut, dates de creació i modificació, dates EXIF, informació de la signatura i qualsevol evidència de manipulació per superposició procedent de l’anàlisi forense del PDF.
  • Puntuacions de coincidència del nom respecte al document d’identitat verificat i respecte a les dades esperades proporcionades en crear la sessió.
  • Camps addicionals relacionats amb el banc (número de compte, IBAN, codi de classificació, número d’encaminament, SWIFT/BIC, sucursal) quan el document és un extracte bancari.
Captura de pantalla de l'informe de comprovant de domicili de Didit que mostra els camps d'adreça extrets i el tipus de document
L’extracció de POA realitza una lectura de text no estructurat, la qual cosa introdueix una latència de 5–15 segons per document. Els webhooks només s’activen quan es completa tot el pas del flux de treball; no facis sondeig de l’endpoint de decisió més sovint que cada 5 s durant aquest període.

On apareix a les respostes de l’API

L’endpoint de decisió retorna el POA com la matriu en plural poa_verifications[] a GET /v3/session/{sessionId}/decision/. Cada entrada és una execució del node de POA al teu flux de treball; les sessions amb diversos passos de POA (p. ex., extracte bancari + factura de serveis públics) produeixen una entrada per cada execució amb el seu propi node_id.
L’estructura següent reflecteix l’esquema canònic; consulta Models de dades.

Esquema

Consulta Comprovant de domicili a la referència de models de dades per veure l’esquema canònic.
Cada entrada a warnings[] és un objecte d’advertència: { feature, risk, additional_data, log_type, short_description, long_description, node_id }, amb feature sempre fixat a "PROOF_OF_ADDRESS" per a aquest informe.

Valors d’estat

status utilitza l’enumeració d’estat a nivell de funcionalitat (FeatureStatusChoices). Les regles d’estat personalitzades configurades al node del flux de treball poden ajustar encara més l’estat calculat; les regles es combinen amb la precedència Declined > In Review > Approved. Consulta Advertències del comprovant de domicili per a la correspondència completa de risc a acció, inclòs el comportament de reintent només per al flux de treball de FUTURE_ISSUE_DATE.

Evidència de manipulació per superposició en PDF

Quan el document enviat és un PDF, document_metadata.overlay_manipulation pot contenir evidència forense de possibles superposicions de text:
  • detected: true quan la comprovació ha trobat evidència de manipulació.
  • analyzed: true quan s’ha pogut analitzar el PDF.
  • analysis_incomplete: hi és i és true només quan el fitxer no s’ha pogut comprovar completament. Allò que s’ha comprovat conserva les seves conclusions on sigui possible, i el document genera POA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT.
  • signals: les comprovacions que s’han activat (duplicate_font_subset, glyph_fragmentation).
  • manipulated_regions: rectangles en coordenades de pàgina que envolten el text possiblement editat. Cada rectangle utilitza l’espai de coordenades de pàgina del PDF (x, y, width, height, page_width, page_height), perquè els revisors puguin ressaltar l’àrea afectada en una vista prèvia del PDF.
El camp és null quan el document no és un PDF o quan el PDF no s’ha pogut analitzar. Quan detected=true, el sistema també emet un avís SUSPECTED_DOCUMENT_MANIPULATION l’additional_data del qual reflecteix els senyals i els rectangles anteriors (tret que hi hagi un senyal més fort —modificació després de la signatura digital, is_tampered=true—, que té prioritat; en aquest cas, additional_data descriu la manipulació de la signatura).

Codis QR i codis de barres

Cada informe de POA inclou detected_codes, que cobreix totes les pàgines processades. Cada element conté: detected_codes és un array buit quan no es troba cap codi compatible. Didit mai no endevina un payload: els codis danyats o il·legibles es poden retornar amb la seva ubicació i parsed_payload: null, mentre que els errors en la detecció de codis no fan fallar la verificació de POA.

Exemples

Aprovat — extracte bancari

Rebutjat — manipulació per superposició + discordança de nom

Relacionat

document_file i extra_files[] són URL presignades que caduquen al cap d’unes 4 hores. Torna a cridar l’endpoint de decisió per actualitzar les URL. Emmagatzema només l’estat de verificació i els camps d’adreça analitzats als teus sistemes; minimitza les dades de documents retingudes.
Darrera modificació el 7 de novembre del 2026