Présentation
La vérification de justificatif de domicile (POA) accepte un seul fichier PDF ou image (TIFF, JPG, JPEG, PNG, WEBP, éventuellement compressé au format ZIP) d’une taille maximale de 15 Mo, effectue la classification du type de document, l’extraction basée sur des LLM ainsi que des analyses médico-légales PDF/EXIF, et renvoie :- L’adresse extraite — à la fois brute et structurée (
street_1,city,region,postal_code, lat/lng). - Les métadonnées du document — taille du fichier, type de contenu, dates de création et de modification, dates EXIF, informations de signature, ainsi que toute preuve de manipulation par superposition issue des analyses médico-légales du PDF.
- Les scores de correspondance de nom par rapport à la pièce d’identité vérifiée et par rapport aux informations attendues fournies lors de la création de la session.
- Les champs supplémentaires liés aux coordonnées bancaires (numéro de compte, IBAN, code guichet, numéro d’acheminement, SWIFT/BIC, agence bancaire) lorsque le document est un relevé bancaire.

L’extraction du justificatif de domicile effectue une lecture de texte non structuré, ce qui introduit une latence de 5 à 15 secondes par document. Les webhooks ne se déclenchent que lorsque l’ensemble de l’étape du workflow est terminée — n’interrogez pas l’endpoint de décision plus d’une fois toutes les 5 s pendant cette fenêtre.
Emplacement dans les réponses d’API
L’endpoint de décision renvoie les POA sous forme du tableau plurielpoa_verifications[] dans GET /v3/session/{sessionId}/decision/. Chaque entrée correspond à une exécution du nœud POA dans votre workflow ; les sessions comportant plusieurs étapes de justificatif de domicile (par ex. un relevé bancaire + une facture d’électricité) génèrent une entrée par exécution avec son propre node_id.
Schéma
Consultez Justificatif de domicile dans la référence des modèles de données pour le schéma canonique.warnings[] est un objet Avertissement : { feature, risk, additional_data, log_type, short_description, long_description, node_id }, avec feature valant toujours "PROOF_OF_ADDRESS" pour ce rapport.
Valeurs de statut
status utilise l’énumération des statuts au niveau de la fonctionnalité (FeatureStatusChoices).
Des règles de statut personnalisées configurées sur le nœud du workflow peuvent ajuster davantage le statut calculé ; les règles se combinent selon l’ordre de priorité Refusé > En cours d’examen > Approuvé. Consultez les Avertissements du justificatif de domicile pour la table de correspondance complète risque-action, y compris le comportement de nouvelle tentative réservé au workflow pour
FUTURE_ISSUE_DATE.
Preuves de manipulation par superposition dans les PDF
Lorsque le document soumis est un PDF,document_metadata.overlay_manipulation peut contenir des preuves forensiques de superpositions de texte suspectées :
detected:truelorsque la vérification a trouvé des preuves de manipulation.analyzed:truelorsque le PDF a pu être analysé.analysis_incomplete: présent ettrueuniquement lorsque le fichier n’a pas pu être vérifié intégralement. Les contrôles effectués conservent leurs résultats lorsque c’est possible, et le document déclenchePOA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT.signals: les contrôles qui se sont déclenchés (duplicate_font_subset,glyph_fragmentation).manipulated_regions: rectangles, exprimés dans les coordonnées de la page, autour du texte suspecté d’avoir été modifié. Chaque rectangle utilise l’espace de coordonnées de page du PDF (x,y,width,height,page_width,page_height) afin que les réviseurs puissent mettre en évidence la zone concernée dans un aperçu du PDF.
null lorsque le document n’est pas un PDF ou lorsque le PDF n’a pas pu être analysé. Lorsque detected=true, le système émet également un avertissement SUSPECTED_DOCUMENT_MANIPULATION dont additional_data reprend les signaux et les rectangles ci-dessus, sauf si un signal plus fort (une modification après la signature numérique, ou is_tampered=true) a eu priorité. Dans ce cas, additional_data décrit à la place la falsification de la signature.
Codes QR et codes-barres
Chaque rapport POA inclutdetected_codes, couvrant chaque page traitée. Chaque élément contient :
detected_codes est un tableau vide si aucun code pris en charge n’est trouvé. Didit ne devine jamais un payload : les codes endommagés ou illisibles peuvent être renvoyés avec leur emplacement et parsed_payload: null, tandis que les échecs de détection de code n’entraînent pas l’échec de la vérification POA.
Exemples
Approuvé — relevé bancaire
Refusé — manipulation par superposition + discordance de nom
Pages connexes
- Avertissements du justificatif de domicile — chaque code d’avertissement que le POA peut émettre
- Présentation du justificatif de domicile — types de documents acceptés et règles de vérification
- Modèles de données — Justificatif de domicile — schéma canonique
- Webhooks —
status.updatedtransporte les payloads de POA
document_file et extra_files[] sont des URL pré-signées qui expirent après environ 4 heures. Réinterrogez l’endpoint de décision pour actualiser les URL. Ne stockez de votre côté que le statut de vérification et les champs d’adresse extraits — minimisez les données de documents conservées.