Passer au contenu principal

Vue d’ensemble

Chaque rapport par fonctionnalité suit la structure du sérialiseur V3 définie dans service-didit-verification. Le même objet apparaît à trois endroits, de sorte que le schéma présenté ici constitue la source unique de vérité pour ces trois emplacements :
  • GET /v3/session/{sessionId}/decision/ — chaque fonctionnalité est renvoyée sous la forme d’un tableau au pluriel (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], poa_verifications[], phone_verifications[], email_verifications[], aml_screenings[], ip_analyses[], database_validations[], questionnaire_responses[], signatures[], bank_verifications[] (voir Méthodes de vérification bancaire), ainsi que les équivalents KYB registry_checks[], document_verifications[], key_people_checks[]).
  • Payloads de webhook (status.updated, data.updated) — même structure à l’intérieur de l’enveloppe decision.
  • API autonomes — les réponses sous forme d’objet unique (Face Search, Age Estimation, Biometric Authentication) réutilisent le même ensemble de champs.
La V3 a introduit les workflows multi-instances : chaque objet de fonctionnalité comporte un champ node_id qui rattache le rapport au nœud du graphe de workflow qui l’a généré. Les endpoints V2 (au singulier kyc, face, aml, etc.) restent rétrocompatibles mais ne renvoient que la première instance.

Champs communs

Chaque objet de rapport expose les éléments suivants : Les champs de médias (portrait_image, front_image, document_file, …) sont des URL pré-signées avec une fenêtre de validité limitée — téléchargez-les rapidement plutôt que de conserver l’URL. Les exemples les présentent sous la forme https://<media-host>/....

Objet d’avertissement

Renvoyé dans chaque tableau warnings[]. Schéma issu de logs/serializers/log.py:8-65 (LogV3Serializer).

Sections de rapport

Les autres sections décrivent chaque objet de rapport propre à une fonctionnalité. Le texte des titres H3 est volontairement stable afin que d’autres documents puissent y renvoyer directement.

Vérification d’identité

Renvoyé pour chaque document KYC/ID soumis par un utilisateur. Apparaît sous id_verifications[] dans GET /v3/session/{sessionId}/decision/ et dans le champ kyc des réponses V2. Source : kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer, hérite de IDVerificationV2Serializer à kyc/serializers/kyc.py:320-380).
Le même objet avec une méthode autre que le document. Seules les clés propres à la méthode changent : tout ce qu’une lecture de document renseigne est alors rempli à partir de l’enregistrement du registre ou des attributs du portefeuille, et les clés non applicables valent null.

Vérification NFC

Renvoyée pour chaque lecture de puce d’un document d’identité : puce de passeport électronique ICAO 9303 ou d’eID, ou carte My Number du Japon lue via JPKI (chip_protocol: "jpki"). Apparaît sous la forme nfc_verifications[] dans GET /v3/session/{sessionId}/decision/ (une par enregistrement KYC parent). Source : kyc/serializers/epassport.py:121-139 (NFCV3Serializer, qui étend NFCV2Serializer dans kyc/serializers/epassport.py:83-118).

Contrôle de détection du vivant

Renvoyé pour chaque session de détection du vivant. Apparaît sous la forme liveness_checks[] dans GET /v3/session/{sessionId}/decision/. Source : face/serializers/face.py:301-320 (LivenessV3Serializer, qui étend LivenessV2Serializer à face/serializers/face.py:216-298).
Une session PASSIVE renvoie ce champ lorsque sa capture a conservé un enregistrement, et null lorsque la session n’en a conservé aucun ; l’exemple ci-dessus correspond à une session qui n’en a conservé aucun.

Correspondance faciale

Renvoyé pour chaque comparaison de correspondance faciale (en général, le visage vivant de l’utilisateur comparé au portrait du document). Apparaît sous la forme face_matches[] dans GET /v3/session/{sessionId}/decision/. Source : face/serializers/face.py:367-389 (FaceMatchV3Serializer, qui étend FaceMatchV2Serializer à face/serializers/face.py:323-364).

Recherche faciale

Renvoyée par l’API autonome de recherche faciale (POST /v3/face-search/). La recherche faciale n’apparaît jamais sous la forme d’un tableau pluriel dans /v3/session/{sessionId}/decision/ : lorsqu’elle est enregistrée avec save_api_request=true, la session y apparaît sous la forme d’une entrée FACE_SEARCH dans features[], ainsi que d’un élément liveness_checks[] contenant les matches enregistrés. Sources : apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer enveloppant FaceSearchDetailsSerializer) ; les dictionnaires de correspondance sont construits dans face/utils/utils.py:869-884. Réponse de premier niveau : Objet face_search :

Objet de correspondance de recherche faciale

Filtrage AML

Renvoyé pour chaque entité filtrée. Apparaît sous la forme aml_screenings[] dans GET /v3/session/{sessionId}/decision/, pour les sessions KYC comme pour les sessions KYB. Source : aml/serializers/aml.py:63-85 (AMLV3Serializer, qui étend AMLV2Serializer en aml/serializers/aml.py:28-60).

Analyse IP

Renvoyé pour chaque emplacement réseau capturé. Apparaît comme ip_analyses[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB. Source : kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3).

Vérification de localisation

Renvoyé pour chaque étape de Vérification de localisation. Apparaît comme geolocation_checks[] dans GET /v3/session/{sessionId}/decision/ : un élément par étape, correspondant à sa tentative acceptée. geolocation_attempts[] liste chaque tentative de chaque étape, de la plus ancienne à la plus récente. Les deux valeurs sont null pour un workflow sans l’étape. Source : GeolocationDecisionSerializer. Tous les champs et exemples figurent dans le Rapport de vérification de la localisation.

Justificatif de domicile

Renvoyé pour chaque document d’adresse soumis. Apparaît sous forme de poa_verifications[] dans GET /v3/session/{sessionId}/decision/. Source : poa/serializers/poa.py:212-227 (POAV3Serializer, hérite de POAV2Serializer à poa/serializers/poa.py:173-209).

Vérification du téléphone

Renvoyé pour chaque tentative de vérification du téléphone. Apparaît sous la forme phone_verifications[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB. Source : phone/serializers/phone.py:251-266 (PhoneV3Serializer, qui hérite de PhoneV2Serializer à phone/serializers/phone.py:103-248).

Vérification de l’e-mail

Renvoyé pour chaque tentative de vérification de l’e-mail. Apparaît sous la forme email_verifications[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB. Source : email_verification/serializers/email.py:149-164 (EmailV3Serializer, qui hérite de EmailV2Serializer à email_verification/serializers/email.py:38-146).

Validation en base de données

Renvoyé pour chaque recherche en base de données effectuée sur les données soumises par l’utilisateur. Apparaît sous la forme database_validations[] dans GET /v3/session/{sessionId}/decision/. Source : database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, qui hérite de DatabaseValidationV2Serializer).

Réponse au questionnaire

Renvoyée pour chaque soumission de questionnaire. Apparaît sous questionnaire_responses[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB. Source : questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, qui étend QuestionnaireResponseSerializer à questionnaires/serializers/questionnaire.py:520-588).

Signature électronique

Renvoyée pour chaque signataire d’une étape de Signature électronique. Apparaît sous signatures[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB, uniquement lorsque le workflow comporte cette étape. Contrairement aux autres objets de rapport, son status correspond à l’étape de signature et son résultat figure dans verdict, et les éléments de warnings[] sont des { code, node_id } et non des objets d’avertissement. Le rapport de signature électronique contient un exemple complet et tous les champs imbriqués.

Estimation de l’âge

Renvoyé par l’API d’estimation de l’âge autonome (POST /v3/age-estimation/). La réponse reprend un sous-ensemble de la structure de Liveness check sous une enveloppe age_estimation (status, method, score, age_estimation, warnings), auquel s’ajoute un bloc user_image de détection de visage propre à l’API autonome. Elle n’inclut pas reference_image, video_url, matches, face_quality ni face_luminance. Dans les sessions de workflow, il n’existe pas de tableau distinct : l’âge estimé apparaît dans liveness_checks[].age_estimation de GET /v3/session/{sessionId}/decision/. Source : apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer), enveloppe assemblée dans apis/views/age_estimation.py:138-174.

Authentification biométrique

L’authentification biométrique exécute le même pipeline de Détection du vivant et de Correspondance faciale que celui du KYC standard, mais configuré pour comparer le visage capturé à l’image de référence d’un utilisateur existant, au lieu d’un portrait de document extrait par OCR. Il n’existe pas de sérialiseur dédié : GET /v3/session/{sessionId}/decision/ renvoie les objets standard Détection du vivant et Correspondance faciale sous liveness_checks[] et face_matches[]. Le workflow de la session est configuré avec workflow_type = "biometric_authentication" (WorkflowTypeChoices, common/config/choices.py:636).

Registre KYB

Renvoyé pour chaque entreprise confirmée par le registre dans un workflow KYB. Apparaît sous la forme registry_checks[] dans GET /v3/session/{sessionId}/decision/ pour les sessions d’entreprise. Source : kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

Objet société

Issu de kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer).

Document KYB

Renvoyé pour chaque nœud qui collecte des documents justificatifs KYB. Apparaît sous la forme document_verifications[] dans GET /v3/session/{sessionId}/decision/ pour les sessions d’entreprise : une entrée par node_id, avec items[] listant chaque document téléversé. Source : kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer) ; chaque élément suit kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer).

Objet d’élément de document KYB

Personne clé KYB

Renvoyée pour chaque nœud de personnes clés d’un workflow KYB. Apparaît sous la forme key_people_checks[] dans GET /v3/session/{sessionId}/decision/ pour les sessions d’entreprise. Source : kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer).

Champs au niveau de la décision

Ces clés figurent aux côtés des tableaux de fonctionnalités sur GET /v3/session/{sessionId}/decision/ et à l’intérieur de la propriété decision d’un webhook. Consultez Récupérer une session pour savoir comment les lire.

Consentement biométrique

Chaque décision de vérification des utilisateurs et chaque webhook de session comporte un objet biometric_consent unique (pas un tableau) : indique si la session nécessitait un consentement biométrique explicite, pourquoi, ainsi que les éléments de preuve de la réponse. Il vaut null lorsque la session n’a jamais été évaluée, par exemple un workflow sans capture de visage. Source : BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). Le moment où l’étape apparaît et la signification de chaque cas sont expliqués dans Consentement biométrique. Les champs sans valeur enregistrée sont null, jamais une chaîne vide. Une session dans l’Illinois traitée par un SDK natif antérieur à la version 4.10.0, qui a capturé le selfie sans l’étape :
Une personne utilisant un VPN dont le point de sortie est situé en dehors des États-Unis, qui a donné son accord dans le flux hébergé :

Référence des énumérations de statut

Deux espaces de valeurs liés partagent le nom de champ status. Chaque objet de rapport par fonctionnalité sur cette page utilise l’énumération au niveau de la fonctionnalité ; le champ status de premier niveau de la session parente utilise l’énumération plus large de la session.

Statuts au niveau de la fonctionnalité

Utilisé par le champ status de chaque objet de rapport. Source : common/config/choices.py:343-348 (FeatureStatusChoices). Les vérifications du téléphone, de l’e-mail et de l’identité peuvent également renvoyer Expired lorsque l’étape correspondante expire (PhoneStatusChoices à common/config/choices.py:377-382, EmailStatusChoices à common/config/choices.py:434-439).

Statuts au niveau de la session

Utilisé par le champ status de premier niveau de la session parente. Source : common/config/choices.py:106-117 (StatusChoices).
Les valeurs terminales d’une session sont Approved, Declined, In Review, Expired, Kyc Expired et Abandoned. Une session peut atteindre sa décision globale alors qu’une fonctionnalité individuelle reste In Review.
Dernière modification le 14 novembre 2026