Zum Hauptinhalt springen
Dieser Leitfaden führt Sie durch den vollständigen Ablauf zur Integration der Identitätsverifizierung von Didit über die REST-API: Anmeldedaten abrufen, eine Sitzung erstellen, sie dem Benutzer anzeigen und Ergebnisse empfangen.

Schritt 1: Anmeldedaten abrufen

Sie haben zwei Möglichkeiten, einen api_key zu erhalten:

Option A: Programmatische Registrierung (ohne Browser)

Ideal für CI/CD und KI-Agenten. Zwei API-Aufrufe – POST /programmatic/register/ gefolgt von POST /programmatic/verify-email/ – geben den api_key direkt zurück. → Siehe Programmatische Registrierung für den vollständigen Ablauf, Passwortregeln, JWT-Gültigkeitsdauer und Sperrrichtlinien.

Option B: Über die Didit Console

  1. Gehen Sie zur Didit Console.
  2. Erstellen oder wählen Sie Ihre Organisation aus.
  3. Navigieren Sie zu Einstellungen → API & Webhooks.
  4. Kopieren Sie:
    • API-Schlüssel – wird als x-api-key-Header bei jedem Verifizierungsaufruf verwendet.
    • Webhook-Geheimschlüssel – wird zur Überprüfung von Webhook-HMAC-Signaturen verwendet.

Umgebungsvariablen


Schritt 2: Einen Workflow erstellen

Bevor Sie Sitzungen erstellen können, benötigen Sie einen Verifizierungs-Workflow. Workflows legen fest, welche Verifizierungsschritte die Benutzer durchlaufen.

In der Console erstellen

  1. Gehen Sie zu Didit Console → Workflows
  2. Klicken Sie auf Workflow erstellen
  3. Wählen Sie eine Basisvorlage aus:
  1. Fügen Sie optionale Funktionen hinzu:
  1. Kopieren Sie Ihre Workflow-ID
Detaillierte Konfigurationsoptionen finden Sie in der Workflow-Dokumentation.

Schritt 3: Verifizierungssitzung erstellen

Rufen Sie die API auf, um eine Sitzung für Ihren Benutzer zu erstellen.

Anfrage

Anfrageparameter

Vollständiges Beispiel mit allen Optionen

expected_details.expected_document_types beschränkt den Schritt der Ausweisverifizierung auf bestimmte Dokumenttypen – der Dokumentauswahlbildschirm zeigt nur die angeforderten Typen an. Zulässige Werte: P (Reisepass), ID (Personalausweis), DL (Führerschein), RP (Aufenthaltstitel), HIC (Krankenversicherungskarte), TC (Steuerkarte), SSC (Sozialversicherungskarte). Bei den Werten wird nicht zwischen Groß- und Kleinschreibung unterschieden und sie werden dedupliziert; unbekannte Werte geben 400 zurück. Siehe die Referenz zu „Sitzung erstellen“ für das vollständige Schema.

Antwort

201 Created:

Wichtigste Antwortfelder

Idempotenz. Wenn vendor_data angegeben ist und bereits eine nicht abgeschlossene Sitzung (Not Started, In Progress, Resubmitted oder Awaiting User) mit demselben vendor_data in der neuesten veröffentlichten Version des Workflows vorhanden ist, wird diese bestehende Sitzung zurückgegeben (weiterhin 201), anstatt ein Duplikat zu erstellen – wobei callback und metadata auf die neuen Werte aktualisiert werden, und wobei status den Status der bestehenden Sitzung widerspiegelt.
Ein fehlender x-api-key gibt 403 zurück mit {"detail": "You do not have permission to perform this action."}, mit demselben Antworttext wie ein gültiger Schlüssel ohne Berechtigung. Ein falscher, widerrufener oder abgelaufener Schlüssel gibt 401 zurück. Unzureichende Credits geben 400 zurück. Siehe API-Referenz zu „Sitzung erstellen“ für die vollständige Dokumentation.

Schritt 4: Verifizierung dem Benutzer präsentieren

Wählen Sie aus, wie Sie den Verifizierungsablauf Ihrem Benutzer präsentieren möchten:

Option A: Natives SDK (empfohlen für mobile Endgeräte)

Verwenden Sie den session_token mit den nativen SDKs für die Kamera-, NFC- und Biometrie-Integration. → iOS SDK · Android SDK · React Native · Flutter

Option B: InContext-iFrame (empfohlen für das Web)

Binden Sie die Verifizierung mithilfe der in Schritt 3 zurückgegebenen url in Ihre Seite ein.
→ InContext-iFrame

Option C: Weiterleitung

Leiten Sie den Benutzer zur Verifizierungs-URL weiter.
→ Web-Weiterleitung

Option D: Mobile WebView

Für mobile Apps ohne natives SDK.
→ WebView in iOS/Android

Schritt 5: Ergebnisse empfangen

Per Webhook (empfohlen)

Webhooks benachrichtigen Ihren Server in Echtzeit, wenn sich der Verifizierungsstatus ändert. Einrichtung:
  1. Erstellen Sie ein Webhook-Ziel in der Console (API & Webhooks) oder über POST /v3/webhook/destinations/ mit webhook_version: "v3" und einem subscribed_events-Array (z. B. ["status.updated"])
  2. Speichern Sie den bei der Erstellung zurückgegebenen secret_shared_key – er ist das HMAC-Geheimnis für alle Signaturvarianten
  3. Implementieren Sie einen Webhook-Endpoint auf Ihrem Server
Beispiel für einen Webhook-Payload: Innerhalb von decision wird jedes Ergebnis pro Funktion als Array im Plural geliefert (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …) – ein Eintrag pro Knoten im Workflow. Dies ist der V3-Vertrag und verbindlich: Implementieren Sie niemals gegen einen singulären Schlüssel wie nfc / id_verification / liveness.
Das decision-Objekt ist nur vorhanden, wenn der status den Wert Approved, Declined, In Review oder Abandoned hat (ein Resubmitted-Ereignis enthält stattdessen resubmit_info). Didit verwendet dieselbe event_id über Wiederholungsversuche und Fan-Out-Ziele hinweg wieder – nutzen Sie diese als Schlüssel für Ihre Idempotenz. Siehe Datenmodelle für alle Arrays im Plural und Felder. Signatur überprüfen (X-Signature-V2, empfohlen): X-Signature-V2 ist HMAC-SHA256 über eine kanonische Neukodierung des JSON-Bodys: ganzzahlige Floats zu Integern gekürzt, Schlüssel rekursiv sortiert, kompakte Trennzeichen, Unicode beibehalten.
→ Vollständige Webhook-Dokumentation, einschließlich der Raw-Bytes-Signatur X-Signature, der veralteten, nur den Envelope umfassenden Signatur X-Signature-Simple und Hinweisen zur Auswahl. Didit unternimmt bei fehlgeschlagenen Zustellungen (5xx, 404, Timeout) bis zu 2 Wiederholungsversuche (~1 Min., dann ~4 Min.) und bricht nach 5 Sekunden per Timeout ab – antworten Sie schnell mit 2xx.

Per API (optional)

Rufen Sie denselben Decision-Payload jederzeit ab:
Die Struktur der Antwort (Arrays im Plural) ist identisch mit dem decision-Objekt im Webhook-Payload, und der Endpoint kann zu jedem Zeitpunkt im Lebenszyklus der Sitzung aufgerufen werden. Verwenden Sie Webhooks für Echtzeit-Updates und behalten Sie API-Aufrufe für Backfills, Audits und Neuerstellungen vor – der /decision/-Endpoint ist auf 600 GET-Anfragen/Min. pro API-Schlüssel limitiert (siehe Rate-Limiting). Fehlersemantik: Eine unbekannte session_id gibt 404 mit {"detail": "Not found."} zurück; Authentifizierungsfehler führen zu 403 – dieser Endpoint gibt niemals 401 zurück. Medien-URLs in der Antwort sind kurzlebige, vorab signierte Links – rufen Sie diese zeitnah ab, anstatt sie dauerhaft zu speichern. → API-Referenz zum Abrufen von Sitzungen

Vollständige Codebeispiele

Node.js / Express

Python / FastAPI


Sitzungsstatus

Dies sind die 10 möglichen Werte für status – exakte Zeichenketten mit Beachtung der Groß-/Kleinschreibung (beachten Sie, dass Kyc Expired ein einzelnes großes K verwendet): Siehe Verifizierungsstatus für den vollständigen Lebenszyklus, Statusübergänge und das Mermaid-Diagramm.

Nächste Schritte

  1. Wählen Sie Ihre Integrationsmethode:
  2. Webhooks konfigurieren: Webhooks
  3. Kapazität planen: Rate-Limiting
  4. Jeden Status behandeln: Verifizierungsstatus
  5. Workflow anpassen: Workflows
  6. Erreichbarkeit der API prüfen: Healthcheck

Benötigen Sie Hilfe?

Zuletzt geändert am 7. November 2026