> ## 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. # Datenbankvalidierung-API: KYC über Behördenregister > Didits API validiert Daten in Behördenregistern: Ab $0.05/Check, 60+ Länder & biometrischer Gesichtsabgleich, sofern Fotos hinterlegt sind. Didits **Datenbankvalidierung** verifiziert die Identitätsdaten einer Person anhand der maßgeblichen Quelle für das jeweilige Land — dem nationalen Personenstandsregister, der Steuerbehörde, dem Wählerverzeichnis, der Wirtschaftsauskunftei oder dem biometrischen Register, bei der bzw. dem das Dokument ursprünglich ausgestellt wurde. Jede Prüfung liefert einen feldweisen Abgleich (`identification_number`, `first_name`, `last_name`, `date_of_birth` und Adressfelder, sofern der Dienst diese verwendet) sowie ein aggregiertes Ergebnis und die zugrunde liegenden Datensatzdetails, sofern verfügbar.Sie ist der stärkste Schutz gegen Betrug durch synthetische Identitäten: Eine gestohlene echte DNI oder CPF scheitert bei der Registerabfrage, und eine frei erfundene Nummer ist in der offiziellen Datenbank überhaupt nicht vorhanden. Die Datenbankvalidierung lässt sich mit unserem biometrischen Gesichtsabgleich in Ländern kombinieren, in denen das Register ein offizielles Foto bereithält (Argentinien über RENAPER, Panama über Tribunal Electoral SIB / SIB Plus). So können Sie nicht nur bestätigen, dass eine Nummer echt ist, sondern auch, dass die **Person vor der Kamera Inhaberin dieser Nummer ist**. Integrations-Prompt für die Datenbankvalidierung \

\````# Goal
Integrate Didit Database Validation (verify identity data against authoritative national registries) into your app. Pick ONE mode.

\# Mode A — Session-based
Use this when Database Validation runs as a step in a hosted Didit flow. Fields are auto-fed into the registry lookup from the steps in front of it — ID Verification, NFC, Liveness, Phone/Email Verification, Proof of Address, Document AI or a Questionnaire. An ID Verification step is not required.

1\. Add the DATABASE_VALIDATION feature to the workflow (Business Console or POST /v3/workflows/). Optionally pin specific services per country.
2\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. See /sessions-api/create-session.
3\. Open session.url for the user (or mount the Web/Mobile SDK).
4\. Fetch the decision — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

Decision surface: `database_validations[]` array on the decision payload.

\# Mode B — Standalone API (server-to-server)
Use when you already have the identity data and want a one-shot registry check.

POST https://verification.didit.me/v3/database-validation/
multipart/form-data — x-api-key: YOUR_API_KEY

curl example (Brazil CPF):
\```bash
curl -X POST 'https://verification.didit.me/v3/database-validation/' \
-H "x-api-key: $DIDIT_API_KEY" \
-F "issuing_state=BRA" \
-F "identification_number=00000000191" \
-F "first_name=Jane" \
-F "last_name=Doe" \
-F "date_of_birth=1990-01-15" \
-F "vendor_data=user-1234"
\```
Returns: { request_id, database_validation: { match_type: "full_match"|"partial_match"|"no_match", validation_type, services_used, match_score, validations: [{ service, status, matched_fields, record_details }], warnings: [...] } }.

\# Important behaviour
\- Use `identification_number` (universal field) — Didit maps it to CPF/RUT/CURP/DNI/etc. by issuing_state.
\- Omit `services` to run the country's default service only. Pass `services=["bra_cpf"]` (etc.) to choose which services run — list several to run more than one.
\- Argentina (`arg_renaper`) and Panama (`pan_sib`) take an extra `selfie` (JPG/PNG/WebP up to 2 MB) and `gender` for biometric face-match against the registry photo.
\- Services flagged `requires_consent=true` in the catalog require `consent=true` (HTTP 400 otherwise).
\- Billing is **per successful service hit** — multi-service requests can produce multiple usage events.

\# Status / match_type
status: "Approved" | "In Review" | "Declined" (per the partial-match / no-match actions configured on the workflow)
match_type: "full_match" | "partial_match" | "no_match"

\# Warnings (LogWarningChoices.DATABASE_VALIDATION)
warnings[] risk codes include:
DATABASE_VALIDATION_NO_MATCH, DATABASE_VALIDATION_PARTIAL_MATCH, COULD_NOT_PERFORM_DATABASE_VALIDATION (biometric outcomes surface via per-service outcome_code, e.g. BIOMETRIC_NO_MATCH).
Full catalogue: /core-technology/database-validation/database-validation-warnings.

\# Failure modes to handle
\- HTTP 400 — service id not eligible for issuing_state, missing required field, missing consent for PAYGO services.
\- HTTP 502 with validation_errors[] — every selected upstream service failed; request is **not billed** and a COULD_NOT_PERFORM_DATABASE_VALIDATION log is written. Retry later or fall back to OCR-only.
\- match_type="no_match" — record not in registry; treat as synthetic identity per policy.
\- match_type="partial_match" — some fields match, others don't (e.g. DOB matches, name doesn't); route to review.

\# See also
\- Canonical schema: /reference/data-models#database-validation
\- Per-feature report: /core-technology/database-validation/database-validation-report
\- Risk catalogue: /core-technology/database-validation/database-validation-warnings
\- Outcome codes: /core-technology/database-validation/database-validation-outcome-codes
\- Full integration playbook: /integration/integration-prompt````

\
## Warum Didit- **Günstigste Preise pro Aufruf.** Ab **\$0.05** pro Prüfung (Dominikanische Republik) bis zu **\$7.00** für die teuersten Spezialquellen. Der Preis wird pro Dienst festgelegt, nicht pro Land — ein Register, das eine hohe Großhandelsgebühr verlangt, wird entsprechend bepreist (finnische National-ID liegt bei **\$2.10**). Entnehmen Sie den Tarif für den genauen Dienst, den Sie aufrufen möchten, stets der [Preistabelle pro Dienst](https://docs.didit.me/de/getting-started/database-validation-pricing.md). Keine monatlichen Mindestabnahmen, keine Plattformgebühren, keine Abrechnung nach Seats — berechnet werden nur erfolgreiche Anfragen. - **Am schnellsten zu integrieren.** [Registrieren Sie sich](https://business.didit.me/), holen Sie sich einen API-Schlüssel aus der Konsole, und Sie können `POST /v3/database-validation/` innerhalb weniger Minuten aufrufen. Kein Verkaufsgespräch, kein Beschaffungsprozess, kein Papierkram für einen Machbarkeitsnachweis — Didit ist vollständig Self-Service. - **Direkte Treffer bei der maßgeblichen Quelle.** RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — kein Scraping durch Aggregatoren. - **Biometrischer Gesichtsabgleich, wo das Register ein offizielles Foto gespeichert hat.** Höherer Konfidenzwert als bei OCR ohne zusätzlichen Integrationsaufwand. - **Produktionsreife Latenz.** p95 typischerweise unter 1.5 s durchgehend, eine vierteljährliche Verfügbarkeit von 99.9%.Die Academy-Lektion zum Lesen eines Verifizierungsergebnisses behandelt die Datenbankvalidierung ab 11:05 und zeigt vollständige, teilweise und nicht übereinstimmende Abgleichergebnisse.[Datenbankvalidierung: vollständige, teilweise und keine Übereinstimmung — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=665\&rel=0\&playsinline=1)## Globale AbdeckungFahren Sie mit der Maus über ein hervorgehobenes Land, um alle dort verfügbaren Datenbankvalidierungsdienste, die Datendomäne (Identität, Finanzen, Biometrie, Adresse, Telekommunikation, …) und den Preis pro Aufruf anzuzeigen. Aktive Länder sind heute produktionsreif; die übrigen werden bei Bedarf auf Kundenanfrage angebunden.Live Database Validation coverageProduction-ready countries and the cheapest live service available in each.LIVE
Show on-demand catalog countries ()
> [!TIP] > > **Ihr Land ist nicht dabei?** Sprechen Sie uns an — unser Katalog umfasst 60+ Länder mit Hunderten von Diensten, die wir bei Bedarf aktivieren, sobald ein Kunde sie benötigt. Neue Integrationen gehen in der Regel innerhalb von 2–3 Wochen live.## Wie eine Datenbankvalidierung abläuftEine Datenbankvalidierung wird niemals spekulativ ausgelöst. Sie wird nur ausgeführt, wenn **alle** der folgenden Punkte zutreffen:1) Für die Sitzung wurde ein abzufragendes Land ermittelt – anhand des `issuing_state` einer [Ausweisverifizierung](https://docs.didit.me/de/core-technology/id-verification/overview.md) oder, wenn der Workflow keinen Schritt zur Ausweisverifizierung enthält, anhand des einzelnen Landes, für das der Schritt zur Datenbankvalidierung konfiguriert ist. 2) Für dieses Land ist mindestens ein Datenbankvalidierungsdienst im Workflow aktiviert. 3) Die Schritte vor dem Schritt zur Datenbankvalidierung haben **jedes erforderliche Feld** geliefert, das der ausgewählte Dienst benötigt.Wenn ein Dienst aktiviert ist, die erforderlichen Felder jedoch nie übermittelt wurden (z. B. wenn die CPF aus einer verschmierten brasilianischen RG nicht extrahiert werden konnte), wird der Dienst übersprungen, **Ihnen wird nichts in Rechnung gestellt** und für die Sitzung wird eine Warnung ausgelöst: `DATABASE_VALIDATION_NOT_APPLICABLE`, wenn das Dokument die Kennung, nach der dieser Dienst abfragt, schlicht nicht enthält; `COULD_NOT_PERFORM_DATABASE_VALIDATION`, wenn sie hätte verfügbar sein sollen, dies aber nicht der Fall war. Beide sind im [Warnungskatalog](https://docs.didit.me/de/core-technology/database-validation/database-validation-warnings.md) aufgeführt.Jemand in Ihrem Team mit Prüfungszugriff auf die Sitzung kann das fehlende Feld dann auf der Sitzungsdetailseite in der Console manuell ausfüllen; beim Speichern wird die Prüfung automatisch erneut ausgelöst. Dies ist eine Aktion für Prüfer, nichts, was der Endbenutzer tun kann – um dem **Benutzer** die Eingabe eines Feldes zu ermöglichen, das sein Dokument nicht enthält, fragen Sie es in einem Fragebogen (oder einer Document AI-Extraktion bzw. einem Wert, den Sie beim Erstellen der Sitzung übermitteln) ab und ordnen Sie es im Schritt zur Datenbankvalidierung wie unten beschrieben zu.### Datenbankvalidierung erfordert keine AusweisverifizierungFrüher setzte ein Schritt zur Datenbankvalidierung einen vorgelagerten Schritt zur Ausweisverifizierung voraus, da die OCR eines Ausweisdokuments die einzige vorgesehene Möglichkeit war, die Daten des Endbenutzers zu erfassen. Das ist nicht mehr der Fall: **Jedes erforderliche Feld deklariert, welche Schritte es liefern können**, und ein Dienst wird verfügbar, sobald Ihr Workflow einen Schritt enthält, der jedes benötigte Feld bereitstellt.| Eingabequelle | Liefert | | - | - | | Ausweisverifizierung | Namen, Geburtsdatum, Adresse, Dokumenten-/Personennummer und die auf einem Ausweis aufgedruckten länderspezifischen Kennungen (Steuernummer, nationale ID, Passnummer, Führerscheinnummer, …) | | NFC | Die per Chip ausgelesene Teilmenge der oben genannten Daten bei höherer Vertrauenswürdigkeit | | Liveness | Das Live-Selfie für gesichtsbiometrische Registerdienste | | Telefonverifizierung | Die verifizierte Telefonnummer | | E-Mail-Verifizierung | Die verifizierte E-Mail-Adresse | | Adressnachweis | Die verifizierte Wohnadresse und deren Bestandteile | | Document AI | Jedes Feld, das Sie einem Ihrer Extraktionsfeldschlüssel zuordnen | | Fragebogen | Jedes Feld, das Sie einer Ihrer Fragen zuordnen | | API-Eingabe | Alles über die eigenständige API – der Aufrufer übermittelt die Werte direkt |Das bedeutet, dass ein **gesichtsbiometrischer Dienst allein auf Basis eines Liveness-Schritts ausgeführt werden kann**, ohne dass sich irgendwo im Workflow ein Ausweisdokument befindet, und ein Dienst, der auf einer Steuernummer, Telefonnummer oder E-Mail basiert, kann durch eine Fragebogenantwort, einen Schritt zur Telefon-/E-Mail-Verifizierung oder eine Document AI-Extraktion erfüllt werden.Zwei Regeln sorgen für Sicherheit:- **Ein Workflow ohne Ausweisverifizierung muss genau ein Land** im Schritt zur Datenbankvalidierung konfigurieren. Ohne einen `issuing_state` aus einem Dokument ist dies das einzige eindeutige Signal dafür, welches nationale Register abgefragt werden soll. Daher führt eine Konfiguration für mehrere Länder ohne Ausweisverifizierung lieber gar nichts aus, anstatt zu raten. - **Die Prüfung auf erforderliche Felder bleibt unverändert.** Ein Dienst, dessen Felder zur Laufzeit nicht alle vorhanden sind, wird übersprungen, bevor ein Anbieter abgefragt wird. Ihnen wird somit niemals eine Datenbank in Rechnung gestellt, die gar nicht abgefragt wurde.#### Zuordnung von Document AI- und FragebogenfeldernExtraktionsfelder von Document AI und Fragen in Fragebögen verwenden *Ihre* Schlüsselnamen, nicht die von Didit. Ein Schlüssel, der exakt mit einem Eingabenamen der Datenbankvalidierung übereinstimmt (`tax_number`, `date_of_birth`, `phone`, …), wird automatisch zugeordnet und erfordert keine Konfiguration. Für alle anderen Felder zeigt der Workflow-Editor beim Schritt zur Datenbankvalidierung eine Auswahlliste für die noch nicht ausgefüllten Felder an, in der Sie jedes Feld auf den Document AI-Feldschlüssel oder die Fragebogenantwort verweisen, die es bereitstellt.In der Console wird ein Dienst, den Ihr Workflow noch nicht ausführen kann, als deaktiviert angezeigt – zusammen mit der Begründung, welche Felder fehlen und welcher Schritt sie bereitstellen würde. Der Editor bietet Ihnen an, diesen Schritt für Sie hinzuzufügen. Sobald er hinzugefügt wurde, werden alle dadurch freigeschalteten Dienste sofort aktiviert.> [!TIP] > > **Praxisbeispiel – eine Kennung, die das Dokument nicht enthält.** Nigerias National-ID-Dienst fragt anhand der 11-stelligen NIN ab, die häufig nicht auf den von Personen hochgeladenen Dokumenten aufgedruckt ist. Wenn man sich also allein auf das Ausweisdokument verlässt, wird die Prüfung für einen großen Teil der Benutzer als nicht anwendbar übersprungen. Platzieren Sie einen **Fragebogen**-Schritt vor dem Schritt zur Datenbankvalidierung, der die NIN abfragt, und ordnen Sie `national_id` dann im Schritt zur Datenbankvalidierung dieser Frage zu. Dieselbe Zuordnung sorgt auch dafür, dass eine Kennung, die sich überhaupt nicht auf einem Dokument befindet – etwa eine Bankverifizierungsnummer oder eine Registernummer eines Unternehmens –, innerhalb eines Workflows verwendet werden kann.Für adressbasierte Dienste unterteilt Didit die einzelne `address` des Ausweisdokuments automatisch in strukturierte Adresselemente:| Didit-Feld | Bedeutung | | - | - | | `address_element_1` | Straßenadresse, einschließlich Hausnummer und Straßentyp | | `address_element_2` | Optionale Wohneinheit, Gebäude, Etage oder zusätzliche Adresszeile | | `address_element_3` | Vorort, Bezirk, Ortschaft oder Nachbarschaft | | `address_element_4` | Stadt, Gemeinde, Bundesland, Provinz oder Region | | `address_element_5` | Postleitzahl |Beim Aufruf der eigenständigen API können Sie entweder eine einzelne `address` oder diese strukturierten Felder direkt übermitteln. Wenn beide vorhanden sind, haben die strukturierten Felder Vorrang. Dienste, die eine Adresssuche erfordern, benötigen `address_element_1` sowie mindestens ein weiteres Adresselement. Kann Didit diese nicht aus dem Ausweisdokument oder dem Adressnachweis im Workflow ableiten, wird der Dienst übersprungen und nicht abgerechnet.Wenn das ermittelte Land überhaupt nicht aktiviert ist, wird der Schritt stillschweigend ohne Warnung und ohne Gebühren übersprungen.![Didit-Ablauf für die Datenbankvalidierung zum Abgleich von Benutzerdaten mit staatlichen Identitätsregistern](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-how-it-works.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=3d5bb0df058265af0d8728cd60a78416)## Das AbgleichergebnisJeder aktivierte Dienst gibt eine feldbezogene Validierung zurück:| Feld | Ergebnisse | | - | - | | `identification_number` | `full_match` · `partial_match` · `no_match` | | `first_name` | `full_match` · `partial_match` · `no_match` | | `last_name` | `full_match` · `partial_match` · `no_match` | | `date_of_birth` | `full_match` · `no_match` | | `address` | `full_match` · `partial_match` · `no_match` |Der aggregierte `match_type` wird wie folgt zusammengefasst:- **`full_match`** — jedes angefragte Feld stimmt mit mindestens einer Quelle überein. - **`partial_match`** — teilweise Übereinstimmung; Weiterleitung an eine Prüfwarteschlange gemäß Ihren Workflow-Regeln. - **`no_match`** — keine Quelle hat die Daten bestätigt; in der Regel abgelehnt.## Wie der Abgleich abgeleitet wird (1×1 / 2×2)Sie müssen „1×1“ oder „2×2“ nicht mehr vorab auswählen – diese Werte werden daraus abgeleitet, wie viele verschiedene Dienste eine vollständige Übereinstimmung für die Eingabedaten zurückgegeben haben:- **1×1-Ergebnis** — ein Dienst hat eine vollständige Übereinstimmung zurückgegeben (eine einzelne maßgebliche Quelle hat die Daten bestätigt). - **2×2-Ergebnis** — zwei oder mehr Dienste haben eine vollständige Übereinstimmung zurückgegeben (unabhängige Bestätigung; die höchste Konfidenz, die wir ausdrücken können).Ein Workflow kann beliebig viele Dienste pro Land aktivieren; abgerechnet wird pro Dienst, der tatsächlich ein Ergebnis zurückgegeben hat. Dienste, deren erforderliche Felder nicht extrahiert werden konnten, werden ohne Berechnung übersprungen.➡️ Siehe **[Abgleichmethoden](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md)** für die vollständige Entscheidungslogik und wie sie mit `partialMatchAction` / `noMatchAction` zusammenwirkt.## Biometrische DatenbankvalidierungDie Personenstandsregister einiger Länder stellen ein biometrisches Template bereit (ein Porträtfoto oder einen Fingerabdruck). Wenn dieses verfügbar ist, kombinieren wir die Registerabfrage mit einem **biometrischen Gesichtsabgleich** gegen das Selfie des Benutzers:- **Argentinien (`arg_renaper`)** — biometrischer Gesichtsabgleich gegen das offizielle, hinterlegte RENAPER-Foto. 100% Abdeckung der Bevölkerung; jeder argentinische Staatsbürger mit einem DNI ist in der Datenbank erfasst. - **Panama (`pan_cedula_sib`, `pan_cedula_sib_plus`)** — biometrischer Gesichtsabgleich gegen den SIB-Dienst des Tribunal Electoral. SIB Plus ist die höherwertige Variante mit strengeren biometrischen Schwellenwerten und umfangreicheren Metadaten zum Abgleich.Für diese Dienste ist das Feld `selfie` **erforderlich**. Innerhalb eines Sitzungsablaufs verwenden wir das Liveness-Selfie wieder (höchste Qualität) und greifen andernfalls auf das Dokumentporträt zurück. Außerhalb einer Sitzung, beim Aufruf der Standalone-API (`POST /v3/database-validation/`, dem oben beschriebenen Modus B), übermitteln Sie das JPEG/PNG selbst.## Globale Identitätsanreicherung`glb_identity_enrichment` ist ein **globaler, reiner Standalone-Dienst** für die Datenbankvalidierung. Aus einer E-Mail-Adresse und/oder einer Telefonnummer ermittelt er zugehörige Personen (Namen, Geburtsdaten, Adressen, Telefonnummern, E-Mails und nationale Ausweisnummern) und gibt einen Übereinstimmungswert für den Namen zurück, der den Standard-[Ergebniscodes](https://docs.didit.me/de/core-technology/database-validation/database-validation-outcome-codes.md) `MATCH` / `PARTIAL_MATCH` / `NO_MATCH` / `DOCUMENT_NOT_FOUND` (mit dem entsprechenden `match_type` von `full_match` / `partial_match` / `no_match`) zugeordnet ist.Da es sich um einen globalen Dienst (`GLB`) handelt, der auf E-Mail/Telefon statt auf das Ausstellungsland eines Dokuments bezogen ist, steht er **im Workflow-Builder nicht zur Verfügung**. Rufen Sie ihn direkt über die Standalone-API auf, indem Sie `issuing_state` auf `GLB` setzen:```json theme={null} POST /v3/database-validation/ { "issuing_state": "GLB", "services": ["glb_identity_enrichment"], "email": "john.doe@example.com", "phone": "+14155552671" } ```Er wird mit **\$0.20 pro Anfrage** abgerechnet (abgerechnet wird nur, wenn der Anbieter ein Ergebnis zurückgibt).## KonfigurationDie Datenbankvalidierung wird pro Workflow in der Konsole konfiguriert. Für jedes Land wählen Sie die spezifischen Dienste aus, die ausgeführt werden sollen; die erforderlichen und optionalen Eingabefelder ergeben sich aus der Vereinigung dieser Dienste. Die Aktion, die bei den Ergebnissen `partial_match` und `no_match` ausgeführt wird, wird separat konfiguriert und kann `approve`, `review` oder `decline` sein.![Didit-Konsole-Einstellungen für die Datenbankvalidierung zur Auswahl länderspezifischer Registerdienste und Ergebnisregeln](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-console.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2e1ac27f07fa9ca9c54108c6fd19a6b3)## Benachrichtigungen zur VerfügbarkeitBehördenregister und andere Quellen fallen von Zeit zu Zeit aus. Während eine Datenbank nicht erreichbar ist, liefern Prüfungen dagegen keine Antwort und werden nicht abgerechnet. Innerhalb eines Workflows wird der Dienst auf [`REGISTRY_UNAVAILABLE`](https://docs.didit.me/de/core-technology/database-validation/database-validation-outcome-codes) aufgelöst. Bei der eigenständigen API tritt derselbe Ausfall in einer von drei Formen auf. Lesen Sie daher die Ergebnisse pro Dienst **und** `database_validation.errors[]`, niemals den HTTP-Status allein:- `200` mit `outcome_code: "REGISTRY_UNAVAILABLE"` für diesen Dienst in `validations`, wenn Didit für diesen Dienst noch ein Ergebnis zu melden hat. - `200` mit diesem Dienst in `database_validation.errors[]` als `code: "empty_provider_response"`, `retryable: true`, wenn er überhaupt keine verwertbare Antwort geliefert hat und ein anderer ausgewählter Dienst dies tat. Der fehlgeschlagene Dienst fehlt dann in `validations` und in `services_used`, sodass `errors[]` die einzige Stelle ist, an der er aufgeführt wird. - `502` mit `validation_errors[].code: "empty_provider_response"` und `retryable: true`, wenn kein ausgewählter Dienst ein verwertbares Ergebnis zurückgegeben hat (siehe [abgelehnte Eingaben und nicht verfügbare Ergebnisse](https://docs.didit.me/de/standalone-apis/database-validation.md#abgelehnte-eingaben-und-nicht-verfügbare-ergebnisse)).Der übergeordnete `status` richtet sich nach den Diensten, die geantwortet haben, sodass er allein kein verlässliches Ausfallsignal ist. Eine Anfrage, bei der nichts zum Abgleichen übrig bleibt, geht auf `In Review`, aber eine Anfrage, bei der mehrere Dienste ausgewählt wurden, kann bei der Übereinstimmung eines anderen Dienstes als `Approved` zurückkommen, während eine ihrer Quellen nicht verfügbar war. Führen Sie den Wiederholungsversuch für den fehlgeschlagenen Dienst aus `errors[]` durch und nicht für die gesamte Anfrage.Keine dieser Formen sagt etwas über die zu verifizierende Person aus.Didit überwacht die Live-Ergebnisse echter Prüfungen, Datenbank für Datenbank, und sendet Ihrer Organisation eine E-Mail, wenn eine Unterbrechung anhält und es sich nicht nur um eine einzelne fehlgeschlagene Anfrage handelt:| E-Mail | Wann sie gesendet wird | Was sie Ihnen mitteilt | | - | - | - | | **Datenbankunterbrechung** | Eine Datenbank schlägt seit mindestens zehn Minuten fehl, wobei fast jede Prüfung in diesem Zeitraum unbeantwortet blieb. Eine kurze Häufung oder ein einzelner Fehler löst sie niemals aus. | Die betroffene Datenbank und das Land sowie der Zeitpunkt, an dem die Ausfälle erstmals festgestellt wurden. Prüfungen liefern möglicherweise kein Ergebnis, bis der Zugriff wiederhergestellt ist; dies bedeutet nicht, dass die übermittelten Identitäten ungültig sind. | | **Datenbankzugriff wiederhergestellt** | Echte Prüfungen antworten seit mindestens fünf Minuten wieder ohne Fehler. Ruhephasen zählen niemals als Wiederherstellung, daher benötigt eine Datenbank mit geringem Datenaufkommen länger, um beide Zustände zu bestätigen. | Wann die Wiederherstellung bestätigt wurde. Verifizierungen, die während der Unterbrechung nicht abgeschlossen werden konnten, werden **nicht** automatisch erneut verarbeitet: Prüfen Sie diese und starten Sie einen Wiederholungsversuch. |Die Benachrichtigungen gehen an die Mitglieder und Abrechnungskontakte jeder Organisation, die in den vorangegangenen 48 Stunden eine Prüfung gegen genau diese Datenbank durchgeführt hat. Es muss nichts konfiguriert werden und es gibt kein Opt-in. Sandbox-Traffic löst sie niemals aus, und ebenso wenig tun dies Fehler, die durch die von Ihnen gesendeten Daten (abgelehnte oder fehlerhafte Eingaben) oder durch Dienste verursacht wurden, die mit Zugangsdaten laufen, die Ihre eigene Organisation anbindet. Eine Prüfung, die über eine Fallback-Quelle beantwortet wurde, gilt als verfügbar, ebenso wie ein eindeutiger Nicht-Treffer.## Preise — zahlen Sie nur für das, was Sie nutzenDie Datenbankvalidierung wird **pro erfolgreicher Abfrage, pro Dienst** zu dem für diesen Dienst veröffentlichten Preis abgerechnet. Die Preise reichen von **\$0.05** pro Prüfung (Dominikanische Republik über die Junta Central Electoral) bis zu **\$7.00** für die teuersten Spezialquellen. Viele Abfragen von Behördenregistern liegen im Bereich von **USD 0.20 bis USD 0.30**, aber eine beträchtliche Anzahl kostet deutlich mehr, da die Quelle selbst mehr verlangt — der finnische Personalausweis (`fin_national_id`) kostet **\$2.10** pro erfolgreicher Abfrage. Bestimmen Sie den Preis für ein Land anhand der jeweiligen Zeile in der [Preistabelle](https://docs.didit.me/de/getting-started/database-validation-pricing.md), niemals anhand einer Spanne. Es gibt keine monatlichen Mindestbeträge, Verpflichtungen oder Plattformgebühren.Sie zahlen nur, wenn ein Dienst ein Ergebnis zurückgibt. Dienste, die aufgrund fehlender Eingabedaten übersprungen werden, werden nicht in Rechnung gestellt, ebenso wenig wie ein Dienst, dessen Quellaufruf selbst fehlschlägt - ein Registerfehler oder ein nicht erreichbares Register (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) bedeutet, dass die Abfrage nie beantwortet wurde, sodass es sich nicht um ein kostenpflichtiges Ergebnis handelt.Jede erfolgreiche Registerabfrage wird ab der ersten abgerechnet, unabhängig davon, ob sie innerhalb eines Workflows oder über die eigenständige API `POST /v3/database-validation/` ausgeführt wird. Sie wird wie jede andere Prüfung von Ihrem Tarifguthaben oder dem Guthaben aus Aufladungen bezahlt, und Ihr Tarifrabatt gilt für den gesamten Preis. Siehe die [Preisseite](https://docs.didit.me/de/getting-started/pricing.md#rabatte).➡️ [Preise für Datenbankvalidierung](https://docs.didit.me/de/getting-started/database-validation-pricing.md) · [Registrieren und API-Schlüssel erhalten](https://business.didit.me/)## Alle Dienste \ \ \ \ \ \
LandISO3DienstBeschreibungPreis (USD)
## Weiterführende Themen- [Abgleichsmethoden](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md) — wie 1×1- / 2×2-Ergebnisse abgeleitet werden und wie darauf reagiert wird. - [Ergebniscodes](https://docs.didit.me/de/core-technology/database-validation/database-validation-outcome-codes.md) — die vollständige Liste der Antwortcodes von Anbietern (verstorben, minderjährig, Dokument nicht gefunden, biometrische Nicht-Übereinstimmung, …) und wie sie auf Sitzungsentscheidungen abgebildet werden. - [Warnungen](https://docs.didit.me/de/core-technology/database-validation/database-validation-warnings.md) — was angezeigt wird, wenn ein Dienst aufgrund fehlender Daten nicht ausgeführt werden kann. - [Berichte](https://docs.didit.me/de/core-technology/database-validation/database-validation-report.md) — monatliche Abrechnungsexporte pro Dienst mit Land, Dienst-ID, Nutzung, Einheitspreis und Gesamtkosten. - [Unterstützte Länder](https://docs.didit.me/de/core-technology/database-validation/database-validation-supported-countries.md) — eine statische Tabellenansicht aller Länder, die wir heute abdecken. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.