> ## 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. # KYC-API-Integration: Vollständiger End-to-End-Leitfaden > Didit REST-API-Integration: Anmeldedaten abrufen, Sitzung erstellen, Link teilen, Webhooks verarbeiten und KYC-Entscheidungen in Minuten abfragen. 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](https://docs.didit.me/de/integration/programmatic-registration.md) für den vollständigen Ablauf, Passwortregeln, JWT-Gültigkeitsdauer und Sperrrichtlinien. ### Option B: Über die Didit Console 1. Gehen Sie zur [Didit Console](https://business.didit.me). 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 ```bash theme={null} # Required DIDIT_API_KEY=your_api_key_here DIDIT_WEBHOOK_SECRET=your_webhook_secret_here # Your workflow ID (from the Console) DIDIT_WORKFLOW_ID=your_workflow_id_here ``` *** ## 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](https://business.didit.me) → **Workflows** 2. Klicken Sie auf **Workflow erstellen** 3. Wählen Sie eine Basisvorlage aus: | Vorlage | Ideal für | | - | - | | **KYC** | Vollständige Identitätsverifizierung mit Ausweisdokument | | **Adaptive Altersverifizierung** | Altersverifizierung mit optionalem Ausweis-Backup | | **Biometrische Authentifizierung** | Erneute Verifizierung wiederkehrender Benutzer | | **Adressverifizierung** | Überprüfung des Adressnachweises | 4. Fügen Sie optionale Funktionen hinzu: | Funktion | Beschreibung | | - | - | | NFC-Verifizierung | Chipdaten von Reisepässen/Ausweisen auslesen | | Liveness-Erkennung | Spoofing mit Selfie-Video verhindern | | Gesichtsabgleich | Selfie mit Dokumentenfoto abgleichen | | Telefonverifizierung | Telefonnummer per SMS verifizieren | | E-Mail-Verifizierung | E-Mail-Adresse verifizieren | | AML-Screening | Abgleich mit Sanktions-/PEP-Listen | | Datenbankvalidierung | Abgleich mit Regierungsdatenbanken | | Geräte- und IP-Analyse | VPNs, Proxys und Geolokalisierung erkennen | 5. Kopieren Sie Ihre **Workflow-ID** > [!NOTE] > > Detaillierte Konfigurationsoptionen finden Sie in der [Workflow-Dokumentation](https://docs.didit.me/de/console/workflows.md). *** ## Schritt 3: Verifizierungssitzung erstellen Rufen Sie die API auf, um eine Sitzung für Ihren Benutzer zu erstellen. ### Anfrage ```bash theme={null} curl -X POST https://verification.didit.me/v3/session/ \ -H "Content-Type: application/json" \ -H "x-api-key: YOUR_API_KEY" \ -d '{ "workflow_id": "your-workflow-id", "callback": "https://yourapp.com/verification-complete", "vendor_data": "user-123" }' ``` ### Anfrageparameter | Parameter | Erforderlich | Beschreibung | | - | - | - | | `workflow_id` | Ja | Ihre Workflow-UUID aus der Konsole. | | `callback` | Nein | URL, zu der der Benutzer nach der Verifizierung weitergeleitet wird. Didit hängt `verificationSessionId` und `status` als Query-Parameter an. Unterstützt benutzerdefinierte Schemas (z. B. `myapp://`). Fällt auf die konfigurierte Callback-URL des Workflows zurück, wenn dieser Parameter weggelassen wird. | | `callback_method` | Nein | Welches Gerät die Weiterleitung verarbeitet: `initiator`, `completer` oder `both`. Standard: `initiator`. | | `vendor_data` | Nein | Ihre interne Benutzerkennung – wird in Webhooks zur Korrelation zurückgegeben. | | `metadata` | Nein | Beliebiges JSON-Objekt, das mit der Sitzung gespeichert und in Webhooks zurückgegeben wird. | | `language` | Nein | Hinweis zur UI-Sprache (ISO 639-1, z. B. `en`, `es`). Die Browsersprache wird automatisch erkannt, wenn dieser Parameter weggelassen wird. | | `contact_details` | Nein | E-Mail-Adresse/Telefonnummer des Benutzers zur Vorausfüllung und für E-Mail-Benachrichtigungen. | | `expected_details` | Nein | Erwartete Benutzerdaten zum Kreuzabgleich mit den verifizierten Daten. | | `portrait_image` | Bedingt | Base64-kodiertes Gesichtsbild (max. 2 MB; JPEG, PNG, WebP oder TIFF). Referenzgesicht für Workflows mit biometrischer Authentifizierung / Workflows, bei denen der Gesichtsabgleich zuerst erfolgt. Optional, wenn der `vendor_data`-Benutzer bereits über ein gespeichertes Gesicht verfügt (genehmigtes Liveness-Gesicht, ePass-Foto, Ausweisporträt oder registriertes Profilgesicht): Didit verwendet dieses automatisch wieder; `400`, wenn keines davon verfügbar ist. | | `sandbox_scenario` | Nein | Nur in der Sandbox verfügbarer Szenario-Slug (z. B. `approve`, `decline_aml_hit`), der die Sitzung automatisch mit magischen Eingaben befüllt. | ### Vollständiges Beispiel mit allen Optionen ```bash theme={null} curl -X POST https://verification.didit.me/v3/session/ \ -H "Content-Type: application/json" \ -H "x-api-key: YOUR_API_KEY" \ -d '{ "workflow_id": "11111111-2222-3333-4444-555555555555", "callback": "https://yourapp.com/verification-complete", "vendor_data": "user-123", "metadata": { "plan": "premium", "signup_source": "mobile-app" }, "contact_details": { "email": "alex.sample@example.com", "email_lang": "en", "send_notification_emails": true, "phone": "+15550101000" }, "expected_details": { "first_name": "John", "last_name": "Doe", "date_of_birth": "1990-01-01", "expected_document_types": ["P", "ID"] } }' ``` > [!NOTE] > > `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“](https://docs.didit.me/de/sessions-api/create-session.md) für das vollständige Schema. ### Antwort `201 Created`: ```json theme={null} { "session_id": "11111111-2222-3333-4444-555555555555", "session_number": 43762, "session_token": "3FaJ9wLqX2Mz", "url": "https://verify.didit.me/session/3FaJ9wLqX2Mz", "vendor_data": "user-123", "metadata": { "plan": "premium", "signup_source": "mobile-app" }, "status": "Not Started", "workflow_id": "11111111-2222-3333-4444-555555555555", "workflow_version": 3, "callback": "https://yourapp.com/verification-complete" } ``` ### Wichtigste Antwortfelder | Feld | Beschreibung | | - | - | | `session_id` | Eindeutige UUID für diese Sitzung. Verwenden Sie sie für `GET /v3/session/{sessionId}/decision/` und Webhooks. | | `session_number` | Für Menschen lesbare Sequenznummer, die in der Didit-Konsole angezeigt wird. | | `session_token` | 12-stelliger URL-sicherer Token, der den Endbenutzer autorisiert, den gehosteten Ablauf zu öffnen, und die nativen SDKs initialisiert (das Web-SDK nimmt stattdessen `url` entgegen). Behandeln Sie ihn wie ein Geheimnis. | | `url` | Gehostete Verifizierungs-URL, zu der der Benutzer weitergeleitet werden kann oder die in einem iFrame eingebettet werden kann. (Feldname ist `url`, nicht `verification_url`.) Wenn die Anfrage `language` enthält, enthält die URL ein Sprachpfadsegment – z. B. `https://verify.didit.me/en/session/3FaJ9wLqX2Mz`. | | `status` | Aktueller Status – `"Not Started"` für eine neu erstellte Sitzung. | | `workflow_id` | Stabile Workflow-Kennung, unter der die Sitzung ausgeführt wird. | | `workflow_version` | Veröffentlichte Workflow-Version, an die die Sitzung bei der Erstellung gebunden wurde. | > [!NOTE] > > **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. > [!NOTE] > > **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“](https://docs.didit.me/de/sessions-api/create-session.md) 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](https://docs.didit.me/de/integration/native-sdks/ios-sdk.md) · [Android SDK](https://docs.didit.me/de/integration/native-sdks/android-sdk.md) · [React Native](https://docs.didit.me/de/integration/native-sdks/react-native-sdk.md) · [Flutter](https://docs.didit.me/de/integration/native-sdks/flutter-sdk.md) ### 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. ```html theme={null} ``` → [InContext-iFrame](https://docs.didit.me/de/integration/web-sdks/incontext-iframe.md) ### Option C: Weiterleitung Leiten Sie den Benutzer zur Verifizierungs-URL weiter. ```javascript theme={null} window.location.href = session.url; ``` → [Web-Weiterleitung](https://docs.didit.me/de/integration/web-sdks/web-redirect.md) ### Option D: Mobile WebView Für mobile Apps ohne natives SDK. ```jsx theme={null} // React Native ``` → [WebView in iOS/Android](https://docs.didit.me/de/integration/web-sdks/webview-in-ios-android.md) *** ## 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](https://business.didit.me) (**API & Webhooks**) oder über [`POST /v3/webhook/destinations/`](https://docs.didit.me/de/management-api/webhook/create-destination) 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`. ```json theme={null} { "event_id": "9c0c8b8a-1111-4222-9333-444444444444", "webhook_type": "status.updated", "timestamp": 1774970000, "created_at": 1774969994, "application_id": "11111111-2222-3333-4444-555555555555", "environment": "live", "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee", "status": "Approved", "workflow_id": "22222222-3333-4444-5555-666666666666", "workflow_version": 4, "vendor_data": "user-123", "metadata": { "plan": "premium" }, "decision": { "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee", "status": "Approved", "id_verifications": [ { "node_id": "id_verification_1", "status": "Approved", "document_type": "Passport", "warnings": [] } ], "liveness_checks": [ { "node_id": "liveness_1", "status": "Approved", "method": "PASSIVE", "score": 95.4, "warnings": [] } ], "face_matches": [ { "node_id": "face_match_1", "status": "Approved", "score": 96.1, "warnings": [] } ], "reviews": [] } } ``` 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](https://docs.didit.me/de/reference/data-models.md) 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. ```javascript theme={null} const crypto = require("crypto"); // Match Didit's float normalisation: whole-valued floats serialise as ints. function shortenFloats(data) { if (Array.isArray(data)) return data.map(shortenFloats); if (data !== null && typeof data === "object") { return Object.fromEntries( Object.entries(data).map(([key, value]) => [key, shortenFloats(value)]) ); } return data; } // Sort object keys recursively before re-stringifying. function sortKeys(obj) { if (Array.isArray(obj)) return obj.map(sortKeys); if (obj !== null && typeof obj === "object") { return Object.keys(obj).sort().reduce((acc, key) => { acc[key] = sortKeys(obj[key]); return acc; }, {}); } return obj; } function verifyWebhook(rawBody, signatureV2, timestamp, secret) { // 1. Reject anything older than 5 minutes const now = Math.floor(Date.now() / 1000); if (Math.abs(now - parseInt(timestamp, 10)) > 300) return false; // 2. Recompute HMAC-SHA256 against the canonical JSON Didit signs const canonical = JSON.stringify(sortKeys(shortenFloats(JSON.parse(rawBody)))); const expected = crypto.createHmac("sha256", secret).update(canonical, "utf8").digest("hex"); // 3. Constant-time compare const a = Buffer.from(expected, "utf8"); const b = Buffer.from(signatureV2, "utf8"); return a.length === b.length && crypto.timingSafeEqual(a, b); } ``` → [Vollständige Webhook-Dokumentation](https://docs.didit.me/de/integration/webhooks.md), 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: ```bash theme={null} curl https://verification.didit.me/v3/session/{session_id}/decision/ \ -H "x-api-key: YOUR_API_KEY" ``` 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](https://docs.didit.me/de/integration/rate-limiting.md)). 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](https://docs.didit.me/de/sessions-api/retrieve-session.md) *** ## Vollständige Codebeispiele ### Node.js / Express ```javascript theme={null} const express = require("express"); const crypto = require("crypto"); const app = express(); // Create verification session app.post("/api/verify", async (req, res) => { const { userId } = req.body; const response = await fetch("https://verification.didit.me/v3/session/", { method: "POST", headers: { "x-api-key": process.env.DIDIT_API_KEY, "Content-Type": "application/json", }, body: JSON.stringify({ workflow_id: process.env.DIDIT_WORKFLOW_ID, callback: `${process.env.APP_URL}/verification-complete`, vendor_data: userId, }), }); const session = await response.json(); // Store session_id associated with user await db.users.update({ where: { id: userId }, data: { verificationSessionId: session.session_id }, }); res.json({ verificationUrl: session.url, // hosted verification URL sessionToken: session.session_token, // for native/web SDKs }); }); // Handle webhook — uses verifyWebhook / shortenFloats / sortKeys from Step 5 app.post( "/api/webhook", express.raw({ type: "application/json" }), (req, res) => { const signature = req.get("X-Signature-V2"); const timestamp = req.get("X-Timestamp"); if ( !verifyWebhook( req.body.toString("utf8"), signature, timestamp, process.env.DIDIT_WEBHOOK_SECRET, ) ) { return res.status(401).json({ error: "Invalid signature" }); } const payload = JSON.parse(req.body); const { event_id, session_id, status, vendor_data } = payload; // Idempotency: the same event_id is reused on retries and fan-out. // Skip events you have already processed (e.g. a processed_events table). // Update user's verification status (status values are case-sensitive strings) if (status === "Approved") { db.users.update({ where: { id: vendor_data }, data: { isVerified: true, verifiedAt: new Date() }, }); } // Return 2xx quickly (Didit's delivery timeout is 5s); do heavy work asynchronously res.json({ received: true }); }, ); app.listen(3000); ``` ### Python / FastAPI ```python theme={null} from fastapi import FastAPI, Request, HTTPException import httpx import hashlib import hmac import json import os import time app = FastAPI() @app.post("/api/verify") async def create_verification(user_id: str): async with httpx.AsyncClient() as client: response = await client.post( "https://verification.didit.me/v3/session/", headers={ "x-api-key": os.environ["DIDIT_API_KEY"], "Content-Type": "application/json" }, json={ "workflow_id": os.environ["DIDIT_WORKFLOW_ID"], "callback": f"{os.environ['APP_URL']}/verification-complete", "vendor_data": user_id } ) session = response.json() return { "verification_url": session["url"], # hosted verification URL "session_token": session["session_token"], # for native/web SDKs } def shorten_floats(data): """Match Didit: whole-valued floats serialise as ints.""" if isinstance(data, dict): return {k: shorten_floats(v) for k, v in data.items()} if isinstance(data, list): return [shorten_floats(x) for x in data] if isinstance(data, float) and data.is_integer(): return int(data) return data @app.post("/api/webhook") async def handle_webhook(request: Request): payload = await request.json() signature = request.headers.get("X-Signature-V2") timestamp = request.headers.get("X-Timestamp") # Verify timestamp freshness if not signature or not timestamp or abs(int(time.time()) - int(timestamp)) > 300: raise HTTPException(status_code=401, detail="Request too old") # Recompute Didit's V2 canonical JSON: shortened floats, sorted keys, # compact separators, Unicode preserved (ensure_ascii=False) canonical = json.dumps( shorten_floats(payload), sort_keys=True, separators=(",", ":"), ensure_ascii=False, ) expected = hmac.new( os.environ["DIDIT_WEBHOOK_SECRET"].encode("utf-8"), canonical.encode("utf-8"), hashlib.sha256 ).hexdigest() if not hmac.compare_digest(signature, expected): raise HTTPException(status_code=401, detail="Invalid signature") # Idempotency: dedupe on payload["event_id"] (reused on retries) if payload["status"] == "Approved": # Update user in database pass return {"received": True} ``` *** ## 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): | Status | Beschreibung | | - | - | | `Not Started` | Sitzung erstellt, aber der Benutzer hat den Link noch nicht geöffnet. | | `In Progress` | Der Benutzer führt die Verifizierung derzeit durch. | | `In Review` | Verifizierung für eine manuelle Prüfung markiert. | | `Approved` | Alle Prüfungen bestanden. | | `Declined` | Eine oder mehrere Prüfungen sind fehlgeschlagen. | | `Resubmitted` | Der Prüfer hat verlangt, dass bestimmte Schritte wiederholt werden. | | `Awaiting User` | Übergeordnete KYB-Sitzung wartet auf den Abschluss der untergeordneten KYC-Parteien. | | `Abandoned` | Der Benutzer hat begonnen, aber nicht innerhalb der vorgegebenen Zeit abgeschlossen. | | `Expired` | Sitzung abgelaufen, bevor der Benutzer den Link geöffnet hat. | | `Kyc Expired` | Zuvor genehmigte Sitzung, deren Dokument das Ablaufdatum überschritten hat. | Siehe [Verifizierungsstatus](https://docs.didit.me/de/integration/verification-statuses.md) für den vollständigen Lebenszyklus, Statusübergänge und das Mermaid-Diagramm. *** ## Nächste Schritte 1. **Wählen Sie Ihre Integrationsmethode**: * Mobile Apps → [Native SDKs](https://docs.didit.me/de/integration/native-sdks/overview.md) * Web-Apps → [Web-SDKs](https://docs.didit.me/de/integration/web-sdks/overview.md) 2. **Webhooks konfigurieren**: [Webhooks](https://docs.didit.me/de/integration/webhooks.md) 3. **Kapazität planen**: [Rate-Limiting](https://docs.didit.me/de/integration/rate-limiting.md) 4. **Jeden Status behandeln**: [Verifizierungsstatus](https://docs.didit.me/de/integration/verification-statuses.md) 5. **Workflow anpassen**: [Workflows](https://docs.didit.me/de/console/workflows.md) 6. **Erreichbarkeit der API prüfen**: [Healthcheck](https://docs.didit.me/de/api-reference/healthcheck.md) ## Benötigen Sie Hilfe? * **Support**: [support@didit.me](mailto:support@didit.me) * **Programmatisches Onboarding**: [Programmatische Registrierung](https://docs.didit.me/de/integration/programmatic-registration.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.