Zum Hauptinhalt springen
Die Funktion Datenbankvalidierung 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

Ü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 (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 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).
  • 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.
Ein null-Wert bedeutet, dass noch kein Datenbankvalidierungs-Schritt ausgeführt wurde.

Schema

Das verbindliche feldweise Schema finden Sie auf der Seite Datenmodelle. Es wird von DatabaseValidationV3Serializer generiert.

Statuswerte

status verwendet das standardmäßige Enum auf Funktionsebene (siehe Status-Enums) — siehe die Status-Enum-Referenz. Das Enum definiert auch Resub Requested, was in der Praxis bei der Datenbankvalidierung nicht vorkommt. Benutzerdefinierte Statusregeln pro Knoten werden auf diesen Basisstatus angewendet. Unter Warnungen der Datenbankvalidierung 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.

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.

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)

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.

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

Zuletzt geändert am 7. November 2026