Passer au contenu principal
La fonctionnalité de Validation en base de données de Didit recoupe les données d’identité de chaque utilisateur avec la source faisant autorité pour ce pays — RENAPER (Argentine), Receita Federal (Brésil), Tribunal Electoral (Panama, avec correspondance faciale biométrique), Junta Central Electoral (République dominicaine), et plus encore — facturée par requête réussie sans minimum mensuel. Chaque entrée dans database_validations[] est un rapport complet de validation en base de données — une exécution d’un nœud de validation en base de données auprès d’un état émetteur. Les résultats du registre par service se trouvent dans le sous-tableau validations[] de cette entrée. Cette page documente la structure JSON afin que vous puissiez analyser les résultats de correspondance, les données source du registre et les scores biométriques renvoyés par chaque service.
Rapport de validation en base de données Didit montrant les types de correspondance et les champs de réponse du registre

Aperçu

Un rapport de validation en base de données est généré chaque fois qu’un nœud de workflow exécute la fonctionnalité de validation en base de données. Chaque entrée du tableau database_validations[] représente une exécution de nœud auprès d’un état émetteur ; si le nœud exécute plusieurs services pour ce pays (par exemple CPF + CNH au Brésil), chaque service apparaît sous la forme d’un élément distinct dans le sous-tableau validations[] de l’entrée. Chaque rapport contient :
  • Le status global de la fonctionnalité — une valeur de FeatureStatusChoices (Not Finished, Approved, Declined, In Review).
  • Un match_type consolidé (full_match, partial_match, no_match, ou null lorsqu’aucun service n’a renvoyé de résultat exploitable) agrégé entre les services via la méthode de correspondance.
  • L’issuing_state (ISO 3166-1 alpha-3) et le validation_type dérivé (one_by_one, two_by_two ou not_enabled — jamais null).
  • Le bloc screened_data — les données fournies par l’utilisateur qui ont été envoyées au registre.
  • Un tableau validations[] — une entrée par service ayant produit un résultat, avec le service_id/service_name du catalogue, l’outcome_code indépendant du fournisseur, un outcome_detail facultatif, la structure validation champ par champ et les source_data nettoyées extraites de la réponse du registre.
  • Un tableau errors[] — les erreurs par service lorsqu’une recherche a échoué ou a été ignorée ; la clé est entièrement omise lorsqu’il n’y a pas d’erreur.
  • Un tableau warnings[] — les événements de risque émis pendant la validation (voir les avertissements de validation en base de données).
  • Un node_id qui identifie le nœud du graphe de workflow ayant produit le rapport (sessions V3 uniquement).

Emplacement dans les réponses de l’API

Le rapport apparaît sous forme de database_validations[] dans GET /v3/session/{sessionId}/decision/ — toujours un tableau JSON, jamais un objet unique. Le tableau contient une entrée par nœud de validation en base de données dans le graphe de workflow ; à son tour, le sous-tableau validations[] de chaque entrée contient un élément par service de registre ayant produit un résultat.
Une valeur null signifie qu’aucune étape de validation en base de données n’a encore été exécutée.

Schéma

Le schéma champ par champ de référence se trouve sur la page Modèles de données. Il est généré par DatabaseValidationV3Serializer.

Valeurs de statut

status utilise l’énumération standard au niveau des fonctionnalités (voir Énumérations de statut) — consultez la Référence des énumérations de statut. L’énumération définit également Resub Requested, qui n’est pas produit en pratique par la Validation en base de données. Des règles de statut personnalisées par nœud s’appliquent par-dessus ce statut de base. Consultez les Avertissements de la Validation en base de données pour connaître les actions configurables et leurs valeurs par défaut.

Codes de résultat

Chaque entrée de validations[] comporte un outcome_code agnostique vis-à-vis des fournisseurs — parmi MATCH, PARTIAL_MATCH, NO_MATCH, DOCUMENT_NOT_FOUND, INVALID_DOCUMENT_FORMAT, INVALID_INPUT, MINOR_BLOCKED, DECEASED, BIOMETRIC_NO_MATCH, BIOMETRIC_IMAGE_UNUSABLE, INCONCLUSIVE, DOCUMENT_SUPERSEDED, REGISTRY_UNAVAILABLE, REGISTRY_ERROR. Notez bien les nuances : NO_MATCH signifie que le registre n’a définitivement pas confirmé les données, INCONCLUSIVE signifie que le registre n’a pas pu trancher dans un sens ou dans l’autre (à orienter vers un examen manuel, pas un refus), et BIOMETRIC_IMAGE_UNUSABLE correspond à un problème technique lié au selfie (à reprendre) — contrairement à BIOMETRIC_NO_MATCH qui est catégorique. Consultez la taxonomie complète et la gestion recommandée sur la page Codes de résultat.

Une entrée par service

Le tableau validations[] contient un élément pour chaque service ayant produit un payload de résultat (un objet validation, source_data, outcome_code ou outcome_detail). Si votre workflow exécute plusieurs services pour le même pays (par exemple Brésil CPF + Brésil CNH), chacun d’eux apparaît séparément avec ses propres service_id, outcome_code et source_data. Le champ récapitulatif match_type agrège les résultats de l’ensemble des services (toute correspondance totale → full_match ; sinon, toute correspondance partielle → partial_match ; sinon no_match), et validation_type est déduit du nombre de services distincts ayant produit une correspondance totale — voir Méthodes de correspondance.

URL d’images pré-signées

Les champs d’image dans source_data (photo, signature) et screened_data (selfie, cnh_qr_code_image, document_image) sont renvoyés sous forme d’URL pré-signées avec une date d’expiration — actualisez-les en appelant à nouveau l’endpoint de décision. Le payload brut du fournisseur en amont n’est délibérément pas exposé via l’API.

Exemples

Approuvé — vérification du statut CPF au Brésil (Receita Federal)

Approuvé — biométrie DNI pour l’Argentine (RENAPER)

Pour l’Argentine, la validation utilise RENAPER avec une correspondance faciale biométrique. La réponse inclut un face_match_score ainsi que des champs d’identité supplémentaires renvoyés par le registre.

En cours d’examen — la vérification auprès du registre n’a pas pu être effectuée

Lorsqu’aucun service ne renvoie de résultat utilisable — champs obligatoires manquants ou mal formatés, ou registre inaccessible — match_type reste à null, validation_type passe à not_enabled, un avertissement COULD_NOT_PERFORM_DATABASE_VALIDATION est émis, et la fonctionnalité passe à In Review jusqu’à ce que les données soient corrigées. Aucun frais n’est facturé pour les services ignorés.
Renseignez le champ manquant depuis la page de détail de la session dans la Console — l’enregistrement relance automatiquement la vérification et efface l’avertissement en cas de succès.

Sur le même sujet

Dernière modification le 7 novembre 2026