Schritt 1: Anmeldedaten abrufen
Sie haben zwei Möglichkeiten, einenapi_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
- Gehen Sie zur Didit Console.
- Erstellen oder wählen Sie Ihre Organisation aus.
- Navigieren Sie zu Einstellungen → API & Webhooks.
- 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.
- API-Schlüssel – wird als
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
- Gehen Sie zu Didit Console → Workflows
- Klicken Sie auf Workflow erstellen
- Wählen Sie eine Basisvorlage aus:
- Fügen Sie optionale Funktionen hinzu:
- 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 densession_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ückgegebenenurl in Ihre Seite ein.
Option C: Weiterleitung
Leiten Sie den Benutzer zur Verifizierungs-URL weiter.Option D: Mobile WebView
Für mobile Apps ohne natives SDK.Schritt 5: Ergebnisse empfangen
Per Webhook (empfohlen)
Webhooks benachrichtigen Ihren Server in Echtzeit, wenn sich der Verifizierungsstatus ändert. Einrichtung:- Erstellen Sie ein Webhook-Ziel in der Console (API & Webhooks) oder über
POST /v3/webhook/destinations/mitwebhook_version: "v3"und einemsubscribed_events-Array (z. B.["status.updated"]) - Speichern Sie den bei der Erstellung zurückgegebenen
secret_shared_key– er ist das HMAC-Geheimnis für alle Signaturvarianten - Implementieren Sie einen Webhook-Endpoint auf Ihrem Server
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.
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.
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: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ürstatus – 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
- Wählen Sie Ihre Integrationsmethode:
- Mobile Apps → Native SDKs
- Web-Apps → Web-SDKs
- Webhooks konfigurieren: Webhooks
- Kapazität planen: Rate-Limiting
- Jeden Status behandeln: Verifizierungsstatus
- Workflow anpassen: Workflows
- Erreichbarkeit der API prüfen: Healthcheck
Benötigen Sie Hilfe?
- Support: support@didit.me
- Programmatisches Onboarding: Programmatische Registrierung