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).

Objets de rapport

Les sections suivantes couvrent chaque objet de rapport par fonctionnalité. Le texte des titres H3 est volontairement stable afin que d’autres documentations puissent pointer vers eux par lien direct.

Vérification d’identité

Renvoyé pour chaque document KYC/d’identité soumis par un utilisateur. Apparaît sous la forme 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, étend IDVerificationV2Serializer à kyc/serializers/kyc.py:320-380).
Le même objet avec une méthode sans document. Seules les clés spécifiques à la méthode changent — tout ce qu’une lecture de document renseigne est extrait de l’enregistrement du registre ou des attributs du portefeuille, et les clés qui ne s’appliquent pas sont à null.

Vérification NFC

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

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, étend LivenessV2Serializer dans face/serializers/face.py:216-298).

Correspondance faciale

Renvoyé pour chaque comparaison faciale (généralement le visage de l’utilisateur issu de la détection du vivant par rapport 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, étend FaceMatchV2Serializer dans 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 forme de tableau contenant plusieurs éléments dans /v3/session/{sessionId}/decision/ — lorsqu’elle est conservée avec save_api_request=true, la session y figure sous la forme d’une entrée FACE_SEARCH dans features[] plus un élément liveness_checks[] contenant les matches enregistrés. Sources : apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer encapsulant FaceSearchDetailsSerializer) ; dictionnaires de correspondance 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é soumise au filtrage. Apparaît sous la forme aml_screenings[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB. Source : aml/serializers/aml.py:63-85 (AMLV3Serializer, étend AMLV2Serializer à aml/serializers/aml.py:28-60).

Analyse de l’IP

Retournée pour chaque emplacement réseau capturé. Apparaît sous la forme 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 la localisation

Renvoyé pour chaque étape de Vérification de la localisation. Apparaît sous la forme geolocation_checks[] dans GET /v3/session/{sessionId}/decision/ : un élément par étape, correspondant à sa tentative acceptée. geolocation_attempts[] répertorie chaque tentative de chaque étape, la plus ancienne en premier. Les deux valent null pour un workflow sans cette étape. Source : GeolocationDecisionSerializer. Chaque champ et exemple figure dans le Rapport de vérification de localisation.

Justificatif de domicile

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

Vérification du téléphone

Renvoyé pour chaque tentative de vérification de 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, étend PhoneV2Serializer dans phone/serializers/phone.py:103-248).

Vérification de l’e-mail

Renvoyé pour chaque tentative de vérification d’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, étend EmailV2Serializer dans email_verification/serializers/email.py:38-146).

Validation en base de données

Renvoyé pour chaque recherche dans la base de données exécuté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, étend DatabaseValidationV2Serializer).

Réponse au questionnaire

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

Signature électronique

Renvoyé pour chaque signataire d’une étape de Signature électronique. Apparaît sous la forme signatures[] dans GET /v3/session/{sessionId}/decision/ pour les sessions KYC et KYB, uniquement lorsque le workflow comprend cette étape. Contrairement aux autres objets de rapport, son champ status indique l’étape de signature et son résultat figure dans verdict, et les éléments de warnings[] sont de la forme { code, node_id } plutôt que des objets d’avertissement. Le rapport de Signature électronique fournit un exemple complet et l’ensemble des champs imbriqués.

Estimation de l’âge

Renvoyé par l’API autonome d’Estimation de l’âge (POST /v3/age-estimation/). La réponse contient un sous-ensemble de la structure de Liveness check sous une enveloppe age_estimation — status, method, score, age_estimation, warnings — plus un bloc de détection faciale user_image réservé au mode autonome ; elle n’inclut pas reference_image, video_url, matches, face_quality ni face_luminance. Dans les sessions de workflow, il n’y a pas de tableau distinct — l’âge estimé apparaît sous la forme liveness_checks[].age_estimation dans 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 utilisé dans le 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’y a pas de sérialiseur dédié — GET /v3/session/{sessionId}/decision/ renvoie les objets standards 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 un 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 Entreprise

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

Document KYB

Renvoyé pour chaque nœud qui collecte des pièces justificatives 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 représentant un élément de document KYB

Personne clé KYB

Renvoyé pour chaque nœud Personnes clés dans 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 7 novembre 2026