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

# API-Referenz Ausweisverifizierung: Didit REST-API

> Didit REST API-Referenz: KYC-, KYB-, AML-, Biometrie- und Transaktionsüberwachung. OpenAPI-Spec, Preise pro Nutzung, $10 kostenlos/Monat.



Prompt für die Integration der eigenständigen API
        Prompt in die Zwischenablage kopieren



      
      

\<pre>

\``Integrate Didit standalone verification APIs into my backend for server-to-server identity checks.

\## Available Standalone APIs

\### Identity & Documents
\- POST /v3/id-verification/ — multipart/form-data: front_image (required), back_image (optional). Returns: { request_id, id_verification: { status, first_name, last_name, document_type, document_number, date_of_birth, nationality, expiration_date, issuing_state, address, parsed_address, warnings[] } }
\- POST /v3/poa/ — multipart/form-data: document (PDF/image). Returns: { request_id, poa: { status, document_type, issuer, poa_address, poa_parsed_address, issue_date, warnings[] } }
\- POST /v3/database-validation/ — JSON: { issuing_state, validation_type, first_name, last_name, date_of_birth, personal_number, ... }. Returns: { request_id, database_validation: { status, validations } }

\### Document AI
\- POST /v3/document-ai/ — multipart/form-data: document (PDF/image), fields (one JSON-encoded array string of { key, name, instruction, type: "text"|"number"|"date", required, is_full_name }, 1-30 items), expected_first_name + expected_last_name OR expected_company_name (+ expected_company_country), document_ai_name_match_score_threshold (default 80), per-risk *_action params. Returns: { request_id, document_ai: { status, extracted_data: { <key>: value|null }, detected_codes[], fields[], name_match_score, name_on_document, warnings[] } }. $0.20 per document.

\### Biometrics & Face
\- POST /v3/passive-liveness/ — multipart/form-data: user_image. Returns: { request_id, passive_liveness: { status, score, method } }
\- POST /v3/face-match/ — multipart/form-data: user_image + ref_image. Returns: { request_id, face_match: { status, score } }
\- POST /v3/face-search/ — multipart/form-data: user_image. Returns: { request_id, face_search: { status, total_matches, matches[] } }
\- POST /v3/age-estimation/ — multipart/form-data: user_image. Returns: { request_id, age_estimation: { status, age_estimation, score } }

\### Compliance
\- POST /v3/aml/ — JSON: { full_name, entity_type, date_of_birth, nationality, document_number, include_adverse_media, include_ongoing_monitoring }. Returns: { request_id, aml: { status, total_hits, hits[], score, entity_type } }

\### Business Verification (KYB)
\- POST /v3/kyb/search/ — JSON: { country_code (required), name, registration_number, tier: "basic" (default) | "shareholders" | "ubo", search_type: "contains", webhook_url, vendor_data, metadata }. `tier` picks the provider chain the search runs on; retrieve the candidate from select (Lite), shareholders or ubo. Up to $0.50 per successful request, separately from profile retrieval; empty results and failures are not charged. Returns: { request_id, kyb_registry: { companies[] ({ kyb_response_id, name, registration_number, status, type, fetch_status }), pagination, search_status, search_resolved } }. `kyb_response_id` is an opaque handle — pass it straight to select/shareholders/ubo, never parse it.
\- POST /v3/kyb/select/ — JSON: { kyb_response_id (from search), save_api_request, vendor_data, metadata }. **Lite** tier, priced per country ([per-country prices](https://docs.didit.me/getting-started/kyb-registry-pricing.md)). Returns: { request_id, kyb_registry: { status, company_name, registration_number, country_code, company_type, incorporation_date, registered_address, officers[], beneficial_owners[], fetch_status, data_resolved, ... } }
\- POST /v3/kyb/shareholders/ and POST /v3/kyb/ubo/ — same JSON shape as select. **Shareholders** and **UBOs** tiers, priced per country; delivered and billed as the highest tier the country's registries can serve. v3 only.

\### Contact Verification
\- POST /v3/email/send/ — JSON: { email }. Sends OTP code.
\- POST /v3/email/check/ — JSON: { email, code }. Verifies OTP.
\- POST /v3/phone/send/ — JSON: { phone, channel }. Sends OTP via SMS/WhatsApp/Telegram.
\- POST /v3/phone/check/ — JSON: { phone, code }. Verifies OTP.

\### Bank Verification
\- POST /v3/bank/account-check/ - JSON: { country (ISO 3166-1 alpha-3), account: { iban } or { account_number, sort_code | routing_number | ifsc | bsb | transit_institution | bank_code } or { clabe } or { cbu_cvu }, holder: { full_name } or { business_name }, vendor_data }. Checks that a bank account belongs to the name, with no session. Returns: { request_id, result: match | close_match | no_match | cannot_verify, holder_name (close_match only), account (masked), vendor_data, created_at }. Billed once per check the bank answers; errors are never billed.

\## Authentication
All requests require: Headers: { "x-api-key": DIDIT_API_KEY }
For file uploads: multipart/form-data. For JSON: Content-Type: application/json.

\## Common Parameters
\- save_api_request (bool, default true): if true, appears in Console > Manual Checks
\- vendor_data (string): your internal ID for tracking

\## Example: ID Verification (Node.js)
const FormData = require('form-data');
const fs = require('fs');
const form = new FormData();
form.append('front_image', fs.createReadStream('./id_front.jpg'));
form.append('back_image', fs.createReadStream('./id_back.jpg'));

const response = await fetch('https://verification.didit.me/v3/id-verification/', {
method: 'POST',
headers: { 'x-api-key': process.env.DIDIT_API_KEY, ...form.getHeaders() },
body: form
});
const result = await response.json();
// result.id_verification.status: "Approved" or "Declined"
// result.id_verification.first_name, .last_name, .document_number, etc.

\## Example: AML Screening
const response = await fetch('https://verification.didit.me/v3/aml/', {
method: 'POST',
headers: { 'x-api-key': process.env.DIDIT_API_KEY, 'Content-Type': 'application/json' },
body: JSON.stringify({
full_name: 'John Doe',
entity_type: 'person',
date_of_birth: '1990-01-15',
nationality: 'US'
})
});
const result = await response.json();
// result.aml.status, result.aml.total_hits, result.aml.hits

\## When to Use Standalone APIs vs Sessions
\- Standalone: you have images/data, server-to-server, batch processing, custom UX
\- Sessions: user-facing flows where Didit handles camera, UX, multi-step, 54 languages

\## Rate Limits
\- Free: 10/min. Paid: 600/min. Exceeded: HTTP 429.

\## Environment Variables
\- DIDIT_API_KEY — from Didit Console > API & Webhooks

\## Docs
\- API Reference: https://docs.didit.me/api-reference/overview
\- Sessions vs APIs: https://docs.didit.me/api-reference/overview
\- Webhooks: https://docs.didit.me/integration/webhooks``

\</pre>



      
      

Einfügen in

Didit bietet **zwei sich ergänzende Ansätze** für die Identitätsverifizierung. Der Unterschied zwischen ihnen ist entscheidend, wenn Sie die passende Integration für Ihren Anwendungsfall auswählen.### [Gehostete Sitzungen](https://docs.didit.me/de/sessions-api/create-session.md)Vollständige Verifizierungsabläufe mit einer vorgefertigten, optimierten Oberfläche. Benutzer interagieren über Weiterleitung, iframe oder das native SDK mit der gehosteten Oberfläche von Didit.### [Eigenständige APIs](https://docs.didit.me/de/standalone-apis/id-verification.md)Direkte Server-zu-Server-API-Aufrufe. Sie senden Daten (Bilder, Dokumente, Namen) und erhalten strukturierte Verifizierungsergebnisse – ohne Endbenutzeroberfläche.***## Gehostete Sitzungen (empfohlen für benutzerseitige Abläufe)Gehostete Sitzungen sind der **empfohlene Ansatz** für die meisten Integrationen. Wenn Sie eine Sitzung erstellen, generiert Didit eine `verification_url`, die Sie Ihrem Benutzer anzeigen. Der Benutzer durchläuft den gesamten Verifizierungsablauf in der optimierten Oberfläche von Didit, und Sie erhalten die Ergebnisse über einen Webhook oder über die API.### So funktioniert es**1. Sitzung erstellen**Ihr Server ruft `POST /v3/session/` mit einer Workflow-ID auf. Didit gibt eine `verification_url` und einen `session_token` zurück.**2. Dem Benutzer bereitstellen**Leiten Sie den Benutzer weiter, binden Sie die Oberfläche per iframe ein oder initialisieren Sie ein natives SDK mit dem Sitzungs-Token.**3. Benutzer schließt die Verifizierung ab**Der Benutzer folgt dem geführten Ablauf in der optimierten Oberfläche von Didit: Erfassung des Ausweises, Liveness-Erkennung und alle weiteren Schritte.**4. Ergebnisse empfangen**Didit sendet einen Webhook mit der Verifizierungsentscheidung an Ihren Server, oder Sie fragen die Ergebnisse regelmäßig über die Abruf-API ab.### Warum Sitzungen empfohlen werden| Vorteil | Details |
| - | - |
| **Optimierte UX** | Die Verifizierungsoberfläche wird weltweit fortlaufend A/B-getestet, um die höchsten Abschlussraten zu erreichen |
| **Kamerasteuerung** | Intelligente Kameraauswahl, automatische Aufnahme, Qualitätsprüfungen und Gerätekompatibilität sind integriert |
| **Geführter Ablauf** | Schrittweise Anleitungen, Echtzeit-Feedback und Fehlerbehandlung für den Benutzer |
| **Mehrfunktions-Workflows** | Mehrere Funktionen (Ausweisverifizierung + Liveness-Erkennung + AML + Telefonverifizierung + E-Mail-Verifizierung) in einem einzigen Ablauf verketten |
| **Sicherheit** | Anti-Spoofing, aktive Liveness-Erkennung und Geräte-Fingerprinting sind in den Ablauf integriert |
| **Compliance** | Audit-Logs auf Sitzungsebene, Einwilligungserfassung und Richtlinien zur Datenaufbewahrung werden automatisch angewendet |
| **Lokalisierung** | 54 Sprachen mit automatischer Browser-Erkennung |
| **Mobil nativ** | Native SDKs für iOS, Android, React Native und Flutter |
| **Kein Wartungsaufwand** | Didit übernimmt alle UI-Aktualisierungen, Browser- und Gerätefehler sowie Sonderfälle bei der Kamera |### Wann Sitzungen verwendet werden- **Onboarding / KYC** – Neue Benutzer registrieren sich und müssen ihre Identität verifizieren
- **Altersverifizierung** – Bestätigen, dass Benutzer die Mindestaltersanforderungen erfüllen
- **Erneute Verifizierung** – Bestehende Benutzer regelmäßig erneut verifizieren
- **Biometrische Authentifizierung** – Benutzer authentifizieren sich mit ihrem Gesicht für sensible Aktionen
- **Mehrstufige Compliance** – Abläufe, die Ausweis + Liveness + AML + Telefon in einem Durchgang erfordern
- Jedes Szenario, in dem der Endbenutzer anwesend ist und direkt interagiert### Sitzungs-Endpoints| Endpoint | Zweck |
| - | - |
| [Sitzung erstellen](https://docs.didit.me/de/sessions-api/create-session.md) | Verifizierungs-URL für einen Benutzer generieren |
| [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md) | Vollständige Ergebnisse und Entscheidung für eine Sitzung abrufen |
| [Sitzungen auflisten](https://docs.didit.me/de/sessions-api/list-sessions.md) | Alle Sitzungen abfragen und filtern |
| [Sitzung löschen](https://docs.didit.me/de/sessions-api/delete-session.md) | Eine Sitzung und alle zugehörigen Daten entfernen |
| [PDF generieren](https://docs.didit.me/de/sessions-api/generate-pdf.md) | Einen Verifizierungsbericht als PDF exportieren |
| [Sitzung teilen](https://docs.didit.me/de/sessions-api/share-session/share.md) | Einen Freigabe-Token für Wiederverwendbares KYC mit einem Partner generieren |
| [Geteilte Sitzung importieren](https://docs.didit.me/de/sessions-api/share-session/import.md) | Eine von einem Partner geteilte Sitzung importieren (Wiederverwendbares KYC) |***## Eigenständige APIs (für die Server-zu-Server-Verarbeitung)Mit eigenständigen APIs können Sie einzelne Verifizierungsfunktionen **direkt von Ihrem Server aus aufrufen**, ohne eine Nutzeroberfläche. Sie senden die Daten (Bilder, Dokumente, Namen) und erhalten strukturierte Ergebnisse.### So funktioniert es**1. Daten senden**Ihr Server ruft einen eigenständigen Endpoint auf (z. B. `POST /v3/id-verification/`) mit den erforderlichen Daten: Bilder, Dokumente oder JSON-Felder.**2. Ergebnisse empfangen**Didit verarbeitet die Anfrage synchron und gibt die strukturierten Verifizierungsergebnisse in der Antwort zurück.### Wann eigenständige APIs verwendet werden sollten| Anwendungsfall | Beispiel |
| - | - |
| **Backend-Verarbeitung** | Sie haben bereits Dokumentbilder aus Ihrer eigenen Erfassungsoberfläche und müssen diese verifizieren |
| **Batch-Verifizierung** | Verarbeitung von Massen-Ausweisdokumenten, die von einem Operations-Team hochgeladen wurden |
| **Individuelle UX** | Sie haben einen eigenen Erfassungsablauf erstellt und möchten Didit nur für die Analyse nutzen |
| **Server-zu-Server-Prüfungen** | AML-Screening einer Kundenliste ohne jegliche Nutzerinteraktion |
| **Automatisierte Pipelines** | CI/CD- oder Cron-basierte Compliance-Nachprüfungen (z. B. tägliche AML-Überwachung) |
| **Integration in bestehende Systeme** | Anbindung der Didit-Verifizierung an Ihr bestehendes Dokumentenmanagementsystem |
| **Einzelfunktionsaufrufe** | Sie benötigen nur eine Funktion (z. B. nur AML-Screening oder nur Gesichtsabgleich) |### Verfügbare eigenständige APIs**Identität & Dokumente**| API | Funktion |
| - | - |
| [Ausweisverifizierung](https://docs.didit.me/de/standalone-apis/id-verification.md) | Daten aus Ausweisdokumenten extrahieren und validieren (Vorder- und Rückseite) |
| [Adressnachweis](https://docs.didit.me/de/standalone-apis/proof-of-address.md) | Adressdokumente prüfen (Versorgungsrechnungen, Kontoauszüge, amtliche Dokumente) |
| [Address Validation](https://docs.didit.me/de/standalone-apis/address-validation.md) | Bestätigen, dass eine Adresse existiert, und die normalisierte Adresse mit Koordinaten zurückgeben |
| [Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/overview.md) | Benutzerdaten mit staatlichen Datenbanken abgleichen |**Document AI**| API | Funktion |
| - | - |
| [Document AI](https://docs.didit.me/de/standalone-apis/document-ai.md) | Die von Ihnen definierten Felder aus beliebigen Dokumenten (PDF oder Bild) extrahieren, mit Namensabgleich und Manipulationsprüfungen |**Biometrie & Gesicht**| API | Funktion |
| - | - |
| [Passive Liveness](https://docs.didit.me/de/standalone-apis/passive-liveness.md) | Anhand eines einzelnen Bildes prüfen, ob eine reale Person anwesend ist (Anti-Spoofing) |
| [Gesichtsabgleich](https://docs.didit.me/de/standalone-apis/face-match.md) | Zwei Gesichter vergleichen, um festzustellen, ob es sich um dieselbe Person handelt |
| [Gesichtssuche](https://docs.didit.me/de/standalone-apis/face-search.md) | Ein Gesicht in allen zuvor verifizierten Sitzungen suchen (1:N) |
| [Altersschätzung](https://docs.didit.me/de/standalone-apis/age-estimation.md) | Das Alter einer Person anhand eines Gesichtsbilds schätzen |**Compliance & Risiko**| API | Funktion |
| - | - |
| [AML-Screening](https://docs.didit.me/de/standalone-apis/aml-screening.md) | Personen oder Unternehmen auf Sanktionen, PEP und Beobachtungslisten prüfen |**Bankverifizierung**| API | Funktion |
| - | - |
| [Kontoprüfung](https://docs.didit.me/de/standalone-apis/bank-account-check.md) | Prüfen, ob ein Bankkonto der von Ihnen angegebenen Person oder dem von Ihnen angegebenen Unternehmen gehört, bevor Sie Geld dorthin senden |**Unternehmensverifizierung (KYB)**| API | Funktion |
| - | - |
| [KYB Registry Search](https://docs.didit.me/de/standalone-apis/kyb-registry-search.md) | Unternehmensregister nach Namen, Registernummer und Land durchsuchen; bis zu \$0.50 pro erfolgreiche Anfrage |
| [KYB Registry Select](https://docs.didit.me/de/standalone-apis/kyb-registry-select.md) | Das vollständige Registerprofil (Organmitglieder, wirtschaftlich Berechtigte, Adressen) für ein ausgewähltes Unternehmen abrufen |***## Direkter Vergleich| | Gehostete Sitzungen | Eigenständige APIs |
| - | - | - |
| **Integrationsaufwand** | Gering: Weiterleitung, iframe oder SDK | Mittel: Sie übernehmen die Datenerfassung und -übermittlung |
| **Nutzerinteraktion** | Ja: Der Nutzer schließt den Ablauf in der Didit-Oberfläche ab | Nein: nur Server-zu-Server |
| **Kamera/Erfassung** | Von Didit übernommen (optimiert) | Sie stellen die Bilder/Daten bereit |
| **Abläufe mit mehreren Funktionen** | Ja: Funktionen in einem Workflow verketten | Eine Funktion pro API-Aufruf |
| **UX-Optimierung** | Laufend A/B-getestet | Sie steuern die UX |
| **Lokalisierung** | 54 Sprachen, automatisch erkannt | Nicht zutreffend (keine Oberfläche) |
| **Webhooks** | Automatische Statusbenachrichtigungen | Nicht zutreffend (synchrone Antwort) |
| **Antwortzeit** | Asynchron (Nutzer schließt in eigenem Tempo ab) | Synchron (Sekunden) |
| **Ideal für** | Nutzerseitiges Onboarding & Verifizierung | Backend-Verarbeitung & Automatisierung |
| **Sichtbarkeit in der Konsole** | Gesamter Sitzungslebenszyklus im Dashboard | Erscheint im Bereich Manuelle Prüfungen |***## Kann ich beides nutzen?**Ja.** Viele Teams kombinieren beide Ansätze:1) **Sitzungen für das Onboarding**: Neue Nutzer durchlaufen bei der Registrierung den vollständigen gehosteten Verifizierungsablauf
2) **Eigenständiges AML für die laufende Überwachung**: Ein Cron-Job prüft alle genehmigten Nutzer nachts erneut anhand aktualisierter Beobachtungslisten
3) **Eigenständige Gesichtssuche zur Erkennung von Duplikaten**: Wenn eine neue Sitzung genehmigt wird, ruft Ihr Server die Gesichtssuche auf, um nach Duplikaten zu suchen
4) **Eigenständige Ausweisverifizierung für operative Zwecke**: Ihr Compliance-Team lädt Dokumente für Prüfungen von Grenzfällen manuell hoch### Beispiel: Kombinierte Architektur| Ihre Anwendung | Didit-API | Typ |
| - | - | - |
| **Registrierungsablauf für Nutzer** | Sessions-API (gehostete Oberfläche) | Nutzerseitig |
| **Nächtliches erneutes AML-Screening** | Eigenständige AML-API | Server-zu-Server |
| **Dokumentenprüfung durch das Ops-Team** | Eigenständige Ausweisverifizierungs-API | Server-zu-Server |
| **Erkennung doppelter Gesichter** | Eigenständige Gesichtssuche-API | Server-zu-Server |***## Erste Schritte### [Schnellstart mit Sitzungen](https://docs.didit.me/de/integration/api-full-flow.md)Erstellen Sie Ihre erste gehostete Verifizierungssitzung in 5 Minuten.### [API-Authentifizierung](https://docs.didit.me/de/getting-started/api-authentication.md)Rufen Sie Ihren API-Schlüssel ab und beginnen Sie, authentifizierte Anfragen zu senden.### [Webhooks einrichten](https://docs.didit.me/de/integration/webhooks.md)Erhalten Sie Echtzeitbenachrichtigungen, wenn sich der Verifizierungsstatus ändert.### [Einen Workflow erstellen](https://docs.didit.me/de/console/workflows.md)Erstellen Sie individuelle Verifizierungsabläufe in der Business Console.***


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.