Zum Hauptinhalt springen
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 (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

​
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

​
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

​
Verfügbare eigenständige APIs

Identität & Dokumente Document AI Biometrie & Gesicht Compliance & Risiko Bankverifizierung Unternehmensverifizierung (KYB)

​
Direkter Vergleich

​
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

​
Erste Schritte

Zuletzt geändert am 7. November 2026