> ## 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. # Datenbankvalidierungsbericht: JSON-Antwort > Didit liefert Datenbankvalidierungsberichte mit Registerquelldaten, Gesichtsabgleich-Scores und Warncodes. Pay-per-Call ab $0.05. Die Funktion [Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/overview.md) von Didit gleicht die Identitätsdaten jedes Benutzers mit der maßgeblichen Quelle des jeweiligen Landes ab – RENAPER (Argentinien), Receita Federal (Brasilien), Tribunal Electoral (Panama, mit biometrischem Gesichtsabgleich), Junta Central Electoral (Dominikanische Republik) und weiteren –, abgerechnet pro erfolgreicher Abfrage ohne monatliche Mindestmengen. Jeder Eintrag in `database_validations[]` ist ein vollständiger Datenbankvalidierungs-Bericht – eine Ausführung eines Datenbankvalidierungs-Knotens für einen Ausstellungsstaat. Die registerbezogenen Ergebnisse der einzelnen Dienste befinden sich im Unter-Array `validations[]` dieses Eintrags. Diese Seite dokumentiert die JSON-Struktur, damit Sie Übereinstimmungsergebnisse, Quelldaten aus Registern und biometrische Scores parsen können, die von den einzelnen Diensten zurückgegeben werden. ![Didit-Datenbankvalidierungs-Bericht mit Übereinstimmungstypen und Registerantwortfeldern](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) ## Übersicht Ein Datenbankvalidierungs-Bericht wird jedes Mal erstellt, wenn ein Workflow-Knoten die Funktion Datenbankvalidierung ausführt. Jeder Eintrag im Array `database_validations[]` repräsentiert **eine Knotenausführung** für **einen Ausstellungsstaat**; führt der Knoten mehrere Dienste für dieses Land aus (beispielsweise CPF + CNH in Brasilien), erscheint jeder Dienst als separates Element im Unter-Array `validations[]` des Eintrags. Jeder Bericht enthält: * Den übergeordneten Funktions-`status` – ein Wert aus [`FeatureStatusChoices`](https://docs.didit.me/de/reference/data-models#status-aufzählung) (`Not Finished`, `Approved`, `Declined`, `In Review`). * Einen zusammenfassenden `match_type` (`full_match`, `partial_match`, `no_match` oder `null`, wenn kein Dienst ein verwertbares Ergebnis geliefert hat), der über die Dienste hinweg anhand der [Abgleichmethode](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md) aggregiert wird. * Den `issuing_state` (ISO 3166-1 alpha-3) und den abgeleiteten `validation_type` (`one_by_one`, `two_by_two` oder `not_enabled` – niemals `null`). * Den Block `screened_data` – die vom Benutzer bereitgestellten Daten, die an das Register gesendet wurden. * Ein Array `validations[]` – ein Eintrag pro Dienst, der ein Ergebnis geliefert hat, mit `service_id`/`service_name` aus dem Katalog, dem anbieterneutralen `outcome_code`, einem optionalen `outcome_detail`, der feldweisen `validation`-Zuordnung und den bereinigten `source_data` aus der Registerantwort. * Ein Array `errors[]` – dienstspezifische Fehler, wenn eine Abfrage fehlschlug oder übersprungen wurde; der Schlüssel wird **vollständig weggelassen**, wenn keine Fehler vorliegen. * Ein Array `warnings[]` – Risikoereignisse, die während der Validierung ausgegeben wurden (siehe [Warnungen der Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/database-validation-warnings.md)). * Eine `node_id`, die angibt, welcher Workflow-Graph-Knoten den Bericht erstellt hat (nur V3-Sitzungen). ## Wo er in API-Antworten erscheint Der Bericht erscheint als **`database_validations[]`** in `GET /v3/session/{sessionId}/decision/` – immer als JSON-Array, niemals als einzelnes Objekt. Das Array enthält einen Eintrag pro Datenbankvalidierungs-Knoten im Workflow-Graphen; wiederum enthält das Unter-Array `validations[]` jedes Eintrags ein Element pro Registerdienst, der ein Ergebnis geliefert hat. ```json theme={null} { "session_id": "11111111-1111-1111-1111-111111111111", "status": "Approved", "database_validations": [ { "node_id": "feature_db_validation_1", "status": "Approved", "...": "..." } ] } ``` Ein `null`-Wert bedeutet, dass noch kein Datenbankvalidierungs-Schritt ausgeführt wurde. ## Schema Das verbindliche feldweise Schema finden Sie auf der Seite [Datenmodelle](https://docs.didit.me/de/reference/data-models.md#datenbankvalidierung). Es wird von `DatabaseValidationV3Serializer` generiert. ```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 } ``` ### Statuswerte `status` verwendet das standardmäßige Enum auf Funktionsebene (siehe [Status-Enums](https://docs.didit.me/de/reference/data-models.md#status-aufzählung)) — siehe die [Status-Enum-Referenz](https://docs.didit.me/de/reference/data-models.md#status-aufzählung). Das Enum definiert auch `Resub Requested`, was in der Praxis bei der Datenbankvalidierung nicht vorkommt. | Status | Bedeutung | | - | - | | `Not Finished` | Die Validierung hat noch kein Ergebnis geliefert (Ausgangszustand; wird auch erfasst, wenn ein eigenständiger Aufruf über alle Services fehlschlägt). | | `Approved` | Es wurde kein Risiko ausgelöst oder die einzigen ausgelösten Risiken sind mit `NO_ACTION` konfiguriert (Standard bei teilweiser Übereinstimmung). | | `Declined` | Ein Ergebnis ohne Übereinstimmung oder mit teilweiser Übereinstimmung, dessen konfigurierte Aktion `DECLINE` ist. | | `In Review` | Ein Ergebnis ohne Übereinstimmung oder mit teilweiser Übereinstimmung, dessen konfigurierte Aktion `REVIEW` ist, oder die Validierung konnte überhaupt nicht ausgeführt werden (`COULD_NOT_PERFORM_DATABASE_VALIDATION` — immer Prüfung). | Benutzerdefinierte Statusregeln pro Knoten werden auf diesen Basisstatus angewendet. Unter [Warnungen der Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/database-validation-warnings.md) finden Sie die konfigurierbaren Aktionen und deren Standardwerte. ### Ergebniscodes Jeder Eintrag in `validations[]` enthält einen anbieterneutralen `outcome_code` — einen aus `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`. Beachten Sie die Unterschiede: `NO_MATCH` bedeutet, dass das Register die Daten definitiv nicht bestätigt hat, `INCONCLUSIVE` bedeutet, dass das Register dies weder bestätigen noch verneinen konnte (zur Prüfung weiterleiten, nicht ablehnen), und `BIOMETRIC_IMAGE_UNUSABLE` ist ein technisches Problem mit dem Selfie (erneut aufnehmen) — im Gegensatz zum definitiven `BIOMETRIC_NO_MATCH`. Die vollständige Taxonomie und empfohlene Behandlung finden Sie auf der Seite [Ergebniscodes](https://docs.didit.me/de/core-technology/database-validation/database-validation-outcome-codes.md). ### Ein Eintrag pro Service Das Array `validations[]` enthält **ein Element für jeden Service, der eine Ergebnis-Payload geliefert hat** (eine `validation`-Map, `source_data`, `outcome_code` oder `outcome_detail`). Wenn Ihr Workflow mehrere Services für dasselbe Land ausführt (zum Beispiel Brasilien CPF + Brasilien CNH), erscheint jeder separat mit eigener `service_id`, eigenem `outcome_code` und eigenen `source_data`. Der zusammenfassende `match_type` aggregiert über alle Services (eine vollständige Übereinstimmung → `full_match`; andernfalls eine partielle Übereinstimmung → `partial_match`; sonst `no_match`), und `validation_type` wird daraus abgeleitet, wie viele verschiedene Services eine vollständige Übereinstimmung ergaben — siehe [Abgleichmethoden](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md). ### Vorab signierte Bild-URLs Bildfelder in `source_data` (`photo`, `signature`) und `screened_data` (`selfie`, `cnh_qr_code_image`, `document_image`) werden als **vorab signierte URLs** zurückgegeben, die ablaufen — aktualisieren Sie diese durch einen erneuten Aufruf des Entscheidungs-Endpoints. Die rohe Upstream-Payload wird über die API bewusst nicht offengelegt. ## Beispiele ### Genehmigt — Brasilien CPF-Statusprüfung (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": [] } ``` ### Genehmigt — Argentinien DNI biometrisch (RENAPER) Für Argentinien nutzt die Validierung RENAPER mit einem biometrischen Gesichtsabgleich. Die Antwort enthält einen `face_match_score` und zusätzliche, vom Register zurückgegebene Identitätsfelder. ```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": [] } ``` ### In Prüfung — Registerabfrage konnte nicht ausgeführt werden Wenn kein Service ein verwertbares Ergebnis liefert — erforderliche Felder fehlen oder sind fehlerhaft, oder das Register ist nicht erreichbar —, bleibt `match_type` auf `null`, `validation_type` ist `not_enabled`, es wird eine Warnung `COULD_NOT_PERFORM_DATABASE_VALIDATION` ausgegeben und die Funktion wechselt zu `In Review`, bis die Daten korrigiert sind. Für übersprungene Services fallen **keine Kosten** an. ```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" } ] } ``` Füllen Sie das fehlende Feld auf der Sitzungsdetailseite in der Console aus — beim Speichern wird die Prüfung automatisch erneut ausgelöst und die Warnung bei Erfolg gelöscht. ## Verwandte Themen * [Übersicht über die Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/overview.md) — wie die API End-to-End funktioniert und unterstützte Register. * [Abgleichmethoden](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md) — wie 1×1- / 2×2-Ergebnisse (`validation_type: one_by_one` / `two_by_two`) abgeleitet werden. * [Ergebniscodes](https://docs.didit.me/de/core-technology/database-validation/database-validation-outcome-codes.md) — vollständige Taxonomie pro Ergebnis mit länderspezifischen Detailcodes. * [Unterstützte Länder und Services](https://docs.didit.me/de/core-technology/database-validation/database-validation-supported-countries.md) — alle Live-Register, erforderliche Felder und Preis pro Aufruf. * [Warnungen der Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/database-validation-warnings.md) — was wir anzeigen, wenn ein Service nicht ausgeführt werden kann. * [Datenmodelle — Datenbankvalidierung](https://docs.didit.me/de/reference/data-models.md#datenbankvalidierung) — verbindliches feldweises Schema. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.