> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Rapport de validation en base de données : réponse JSON > Analysez les réponses Didit de validation en base de données : registres sources, correspondance faciale et avertissements. À l'appel dès $0.05. La fonctionnalité de [Validation en base de données](https://docs.didit.me/fr/core-technology/database-validation/overview.md) 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](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-report.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=56284966659e33d1c74385647537e5d9) ## 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`](https://docs.didit.me/fr/reference/data-models#référence-des-énumérations-de-statut) (`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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-matching-methods.md). * 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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-warnings.md)). * 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. ```json theme={null} { "session_id": "11111111-1111-1111-1111-111111111111", "status": "Approved", "database_validations": [ { "node_id": "feature_db_validation_1", "status": "Approved", "...": "..." } ] } ``` 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](https://docs.didit.me/fr/reference/data-models.md#validation-en-base-de-données). Il est généré par `DatabaseValidationV3Serializer`. ```typescript theme={null} interface DatabaseValidation { node_id: string | null; status: "Not Finished" | "Approved" | "Declined" | "In Review"; // FeatureStatusChoices issuing_state: string | null; // ISO 3166-1 alpha-3, e.g. "ARG" validation_type: "one_by_one" | "two_by_two" | "not_enabled"; // derived, never null match_type: "full_match" | "partial_match" | "no_match" | null; // null when no service returned a usable result screened_data: { // What we sent to the registry (varies by country/service) tax_number?: string; personal_number?: string; document_number?: string; first_name?: string; last_name?: string; date_of_birth?: string; // YYYY-MM-DD selfie?: string; // Presigned URL (biometric services) cnh_qr_code_image?: string; // Presigned URL (Brazil CNH QR + face match) document_image?: string; // Presigned URL (services that take a document image) gender?: string; // Biometric registry services (e.g. Argentina RENAPER) }; validations: Array<{ // Catalog metadata service_id?: string; // e.g. "arg_renaper" service_name?: string; // e.g. "Argentina - DNI verification (RENAPER)" // Per-field match outcome — keys vary by service // (full_name, first_name, last_name, date_of_birth, identification_number, address, …) validation?: Record; outcome_code?: string; // Vendor-neutral outcome, see below outcome_detail?: string; // Raw upstream status detail backing the outcome code source_data?: { // Cleaned registry record identification_number?: string; first_name?: string; last_name?: string; full_name?: string; date_of_birth?: string; place_of_birth?: string; gender?: string; nationality?: string; issue_date?: string; expiration_date?: string; photo?: string; // Pre-signed JPEG URL signature?: string; // Pre-signed JPEG URL face_match_score?: number; // Biometric services only (0-100) }; }>; errors?: Array<{ // Omitted entirely when empty service_id: string; code?: string; // e.g. "invalid_screened_data", "empty_provider_response" message?: string; missing_required_fields?: string[]; invalid_format_fields?: string[]; field_reasons?: Record; }>; warnings: Warning[]; // See /reference/data-models#warning-object } ``` ### Valeurs de statut `status` utilise l'énumération standard au niveau des fonctionnalités (voir [Énumérations de statut](https://docs.didit.me/fr/reference/data-models.md#référence-des-énumérations-de-statut)) — consultez la [Référence des énumérations de statut](https://docs.didit.me/fr/reference/data-models.md#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. | Statut | Signification | | - | - | | `Not Finished` | La validation n'a pas encore produit de résultat (état initial ; également enregistré lorsqu'un appel autonome échoue sur l'ensemble des services). | | `Approved` | Aucun risque ne s'est déclenché, ou les seuls risques déclenchés sont configurés sur `NO_ACTION` (valeur par défaut pour une correspondance partielle). | | `Declined` | Un résultat de non-correspondance ou de correspondance partielle dont l'action configurée est `DECLINE`. | | `In Review` | Un résultat de non-correspondance ou de correspondance partielle dont l'action configurée est `REVIEW`, ou la validation n'a pas pu être exécutée du tout (`COULD_NOT_PERFORM_DATABASE_VALIDATION` — systématiquement en cours d'examen). | 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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-warnings.md) 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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-outcome-codes.md). ### 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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-matching-methods.md). ### 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) ```json theme={null} { "node_id": "feature_db_validation_1", "status": "Approved", "issuing_state": "BRA", "validation_type": "one_by_one", "match_type": "full_match", "screened_data": { "tax_number": "12345678900", "first_name": "John", "last_name": "Doe", "date_of_birth": "1980-01-01" }, "validations": [ { "service_id": "bra_cpf", "service_name": "Brazil - CPF status check", "outcome_code": "MATCH", "outcome_detail": "200", "validation": { "full_name": "full_match", "date_of_birth": "full_match", "identification_number": "full_match" }, "source_data": { "identification_number": "12345678900", "first_name": "JOHN", "last_name": "DOE", "date_of_birth": "1980-01-01", "lgpd_minor": false, "minor_under_16": false, "minor_under_18": false } } ], "warnings": [] } ``` ### 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. ```json theme={null} { "node_id": "feature_db_validation_1", "status": "Approved", "issuing_state": "ARG", "validation_type": "one_by_one", "match_type": "full_match", "screened_data": { "document_number": "12345678", "selfie": "https:///sessions//selfie.jpg?X-Amz-Signature=...", "gender": "M", "first_name": "John", "last_name": "Doe" }, "validations": [ { "service_id": "arg_renaper", "service_name": "Argentina - DNI verification (RENAPER)", "outcome_code": "MATCH", "validation": { "full_name": "full_match", "identification_number": "full_match" }, "source_data": { "identification_number": "12345678", "first_name": "John", "last_name": "Doe", "full_name": "John Doe", "date_of_birth": "1990-01-01", "tax_id": "20000000019", "tax_id_type": "CUIT", "face_match_score": 97 } } ], "warnings": [] } ``` ### 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. ```json theme={null} { "node_id": "feature_db_validation_1", "status": "In Review", "issuing_state": "PAN", "validation_type": "not_enabled", "match_type": null, "screened_data": { "first_name": "John", "last_name": "Doe", "date_of_birth": "1990-01-01", "selfie": "https:///sessions//selfie.jpg?X-Amz-Signature=..." }, "validations": [], "errors": [ { "code": "invalid_screened_data", "message": "Database validation was skipped before calling the provider because the screened data has missing required fields: personal_number.", "missing_required_fields": ["personal_number"], "service_id": "pan_cedula_sib_plus" } ], "warnings": [ { "feature": "DATABASE_VALIDATION", "risk": "COULD_NOT_PERFORM_DATABASE_VALIDATION", "additional_data": { "reason": "Database validation was skipped before any provider request because the screened data is incomplete or invalid.", "database_validation_errors": [ { "code": "invalid_screened_data", "message": "Database validation was skipped before calling the provider because the screened data has missing required fields: personal_number.", "missing_required_fields": ["personal_number"], "service_id": "pan_cedula_sib_plus" } ], "missing_required_fields_by_service": { "pan_cedula_sib_plus": ["personal_number"] }, "invalid_format_fields_by_service": {}, "field_reasons_by_service": {} }, "log_type": "warning", "short_description": "Could not perform database validation", "long_description": "The system couldn't perform the database validation, please fill the required fields for this country to automatically proceed with database validation.", "node_id": "feature_db_validation_1" } ] } ``` 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 * [Vue d'ensemble de la Validation en base de données](https://docs.didit.me/fr/core-technology/database-validation/overview.md) — fonctionnement de l'API de bout en bout et registres pris en charge. * [Méthodes de correspondance](https://docs.didit.me/fr/core-technology/database-validation/database-validation-matching-methods.md) — déduction des résultats 1×1 / 2×2 (`validation_type: one_by_one` / `two_by_two`). * [Codes de résultat](https://docs.didit.me/fr/core-technology/database-validation/database-validation-outcome-codes.md) — taxonomie complète par résultat avec les codes de détail spécifiques à chaque pays. * [Pays et services pris en charge](https://docs.didit.me/fr/core-technology/database-validation/database-validation-supported-countries.md) — liste de tous les registres disponibles, champs requis et prix par appel. * [Avertissements de la Validation en base de données](https://docs.didit.me/fr/core-technology/database-validation/database-validation-warnings.md) — éléments signalés lorsqu'un service ne peut pas s'exécuter. * [Modèles de données — validation en base de données](https://docs.didit.me/fr/reference/data-models.md#validation-en-base-de-données) — schéma champ par champ de référence. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.