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.

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 tableaudatabase_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
statusglobal de la fonctionnalité — une valeur deFeatureStatusChoices(Not Finished,Approved,Declined,In Review). - Un
match_typeconsolidé (full_match,partial_match,no_match, ounulllorsqu’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 levalidation_typedérivé (one_by_one,two_by_twoounot_enabled— jamaisnull). - 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 leservice_id/service_namedu catalogue, l’outcome_codeindépendant du fournisseur, unoutcome_detailfacultatif, la structurevalidationchamp par champ et lessource_datanettoyé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_idqui 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 dedatabase_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.
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é parDatabaseValidationV3Serializer.
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 devalidations[] 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 tableauvalidations[] 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 danssource_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 unface_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.
Sur le même sujet
- Vue d’ensemble de la Validation en base de données — fonctionnement de l’API de bout en bout et registres pris en charge.
- Méthodes de correspondance — déduction des résultats 1×1 / 2×2 (
validation_type: one_by_one/two_by_two). - Codes de résultat — taxonomie complète par résultat avec les codes de détail spécifiques à chaque pays.
- Pays et services pris en charge — liste de tous les registres disponibles, champs requis et prix par appel.
- Avertissements de la Validation en base de données — éléments signalés lorsqu’un service ne peut pas s’exécuter.
- Modèles de données — validation en base de données — schéma champ par champ de référence.