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.

Übersicht
Ein Datenbankvalidierungs-Bericht wird jedes Mal erstellt, wenn ein Workflow-Knoten die Funktion Datenbankvalidierung ausführt. Jeder Eintrag im Arraydatabase_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 ausFeatureStatusChoices(Not Finished,Approved,Declined,In Review). - Einen zusammenfassenden
match_type(full_match,partial_match,no_matchodernull, 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 abgeleitetenvalidation_type(one_by_one,two_by_twoodernot_enabled– niemalsnull). - 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, mitservice_id/service_nameaus dem Katalog, dem anbieterneutralenoutcome_code, einem optionalenoutcome_detail, der feldweisenvalidation-Zuordnung und den bereinigtensource_dataaus 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 alsdatabase_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.
null-Wert bedeutet, dass noch kein Datenbankvalidierungs-Schritt ausgeführt wurde.
Schema
Das verbindliche feldweise Schema finden Sie auf der Seite Datenmodelle. Es wird vonDatabaseValidationV3Serializer 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 invalidations[] 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 Arrayvalidations[] 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 insource_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 einenface_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 —, bleibtmatch_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.
Verwandte Themen
- Übersicht über die Datenbankvalidierung — wie die API End-to-End funktioniert und unterstützte Register.
- Abgleichmethoden — wie 1×1- / 2×2-Ergebnisse (
validation_type: one_by_one/two_by_two) abgeleitet werden. - Ergebniscodes — vollständige Taxonomie pro Ergebnis mit länderspezifischen Detailcodes.
- Unterstützte Länder und Services — alle Live-Register, erforderliche Felder und Preis pro Aufruf.
- Warnungen der Datenbankvalidierung — was wir anzeigen, wenn ein Service nicht ausgeführt werden kann.
- Datenmodelle — Datenbankvalidierung — verbindliches feldweises Schema.