Zum Hauptinhalt springen

Übersicht

Didit ist die agentenfreundlichste Plattform für die Identitätsverifizierung. KI-Coding-Agenten (Cursor, Claude Code, GitHub Copilot, Devin, OpenHands, Codex) können sich registrieren, Workflows konfigurieren und mit der Verifizierung von Identitäten beginnen – vollständig programmatisch, ohne jemals einen Browser zu öffnen. Warum Agenten Didit lieben:
  • 2 API-Aufrufe von null bis zu den Anmeldedaten (register + verify-email).
  • Kein Browser erforderlich – vollständig ohne Benutzeroberfläche, ideal für CI/CD- und Agenten-Workflows.
  • Kein zweiter Faktor bei einem neuen API-Konto: Tokens werden direkt nach der E-Mail-Verifizierung zurückgegeben.
  • Automatisch bereitgestellte Organisation und Anwendung mit api_key in der Antwort auf die Verifizierung.
  • Vollständige Verwaltungs-API – Workflows, Fragebögen, Listen und Abrechnung konfigurieren, alles per API.
  • MCP-Server verfügbar – Agenten können Didit-Tools nativ erkennen und nutzen.
Der vollständige Vertrag ist als openapi-auth.json veröffentlicht; die folgenden Endpoints wurden dagegen abgeglichen.

Basis-URL

Alle Endpoints in diesem Leitfaden befinden sich auf dem Auth-Host:
Dies ist ein anderer Host als der für die Verifizierungs-API (https://verification.didit.me/v3). Der Auth-Host stellt JWT-Access-Tokens aus und verwaltet Anwendungen. Der Verifizierungs-Host verarbeitet Sitzungen und führt AML-Prüfungen, Workflows usw. aus, authentifiziert mit dem langlebigen api_key, den Sie aus diesem Ablauf erhalten.

Schnellstart

Verwenden Sie eine echte, zustellbare E-Mail-Adresse. Der Endpoint sendet den Verifizierungscode synchron, sodass reservierte Test-Domains (@example.com, @example.org, @*.test, @*.example, @*.invalid) bei der E-Mail-Zustellung abgelehnt werden und der Aufruf einen 500 zurückgibt. Ersetzen Sie den Platzhalter you@yourdomain.com unten durch einen Posteingang, auf den Sie Zugriff haben.

Schritt 1: Registrieren

Antwort (201 Created):
Ein 6-stelliger alphanumerischer Verifizierungscode (z. B. A3K9F2) wird per E-Mail an die Adresse gesendet. Der Code läuft 10 Minuten nach dem Versand ab – wenn er abgelaufen ist, rufen Sie diesen Endpoint erneut mit derselben E-Mail-Adresse und demselben Passwort auf: Bei einem noch nicht verifizierten Konto gibt er 200 mit "A new verification code has been sent to your email." und einem frischen Code zurück. Ein dedizierter POST /programmatic/resend-otp/-Endpoint (Body: {"email", "password"}) sendet den Code ebenfalls erneut, mit einer 60-Sekunden-Abklingzeit zwischen den Sendevorgängen; beide Routen unterliegen demselben Registrierungs-Rate-Limit unten.

Schritt 2: Code verifizieren und Anmeldedaten abrufen

Antwort (200 OK):
Sie haben nun alles, was Sie benötigen. Speichern Sie application.api_key sicher und senden Sie ihn als x-api-key-Header bei jedem Aufruf der Verifizierungs-API mit.
Tokens sind RS256-signierte JWTs. expires_in ist standardmäßig auf 86400 Sekunden (24 Stunden) gesetzt. Das Access-Token wird nur für die Verwaltungs-Endpoints auf apx.didit.me/auth/v2 benötigt – der Traffic der Verifizierungs-API auf verification.didit.me/v3 wird mit dem langlebigen api_key authentifiziert, nicht mit dem JWT.

Schritt 3: API verwenden

Nachfolgende Anmeldungen

Tauschen Sie auf jedem künftig verwendeten Rechner Ihre E-Mail-Adresse und Ihr Passwort gegen ein neues JWT ein:
Gibt direkt access_token + refresh_token zurück – kein Browser erforderlich. Rufen Sie von dort aus GET /organizations/me/ auf, um Ihre org_id (die uuid der Organisation) zu ermitteln, dann GET /organizations/me/{org_id}/applications/, um die Anwendungen der Organisation aufzulisten (die uuid jedes Eintrags ist eine app_id), und schließlich GET /organizations/me/{org_id}/applications/{app_id}/, um den api_key abzurufen.
Über die Konsole erstellte E-Mail/Passwort-Konten können POST /programmatic/login/ ebenfalls verwenden, sobald die E-Mail-Adresse verifiziert ist. Reine OAuth-Konsolenkonten müssen vor der Verwendung dieses Login-Endpoints ohne Benutzeroberfläche ein Passwort festlegen.

Wenn bei der Anmeldung mehr erforderlich ist

POST /programmatic/login/ gibt Tokens nur zurück, wenn das Konto keinen zweiten Faktor hat. Drei weitere Antworten sind möglich, und ein Agent, der die Anmeldung per Skript steuert, sollte diese verarbeiten: Ein API-Schlüssel erfordert keine Anmeldung. Verwenden Sie daher einen solchen für alle automatisierten Abläufe: Ein Konto mit einem zweiten Faktor kann die Anmeldung über diesen Endpoint nicht abschließen.

Passwortanforderungen

Serverseitig erzwungen, eine Regel nach der anderen – der erste Fehler bricht vorzeitig mit einem reinen Array-Fehler wie ["Password must contain at least one uppercase letter."] ab. (Andere Validierungsfehler an diesem Endpoint verwenden die feldspezifische {"password": [...]}-Struktur. Das reine Array-Format bei Regeln zur Passwortstärke ist eine bekannte serverseitige Inkonsistenz; behandeln Sie es im Client-Code wie {"password": [...]}.)

Rate-Limits und Sperren

Drei unabhängige Kontrollmechanismen schützen den Auth-Host. Jeder davon kann eine 429-Antwort auslösen; der Retry-After-Response-Header gibt an, wie lange Sie warten müssen. Ein 429-Body sieht wie folgt aus:
Rate-Limits der Verification API (z. B. 600 Sitzungen/Min.) sind unabhängig und unter Rate-Limits dokumentiert.

Anwendungen verwalten

Sobald Sie authentifiziert sind, können Sie Anwendungen innerhalb Ihrer Organisation abrufen, erstellen oder aktualisieren. Dies eignet sich ideal für Reseller, die eine Anwendung pro Kunde wünschen. Jede Anwendung hat ihre eigene client_id, ihren eigenen api_key, eigene Metadaten und Einstellungen. Es ist auch nützlich, wenn Ihre Organisation unterschiedliche Produkte, Marken, Regionen, Umgebungen oder Anwendungsfälle voneinander trennen möchte.
Das Auflisten, Erstellen oder Aktualisieren von Anwendungen erfordert, dass der Benutzer owner oder admin der Zielorganisation ist; andernfalls lautet die Antwort 403.

Was können Agenten nach der Registrierung tun?

Mit dem api_key haben Agenten vollen Zugriff auf die Verification API. Auditierte Pfade auf https://verification.didit.me/v3: Den vollständigen Umfang finden Sie in der Management-API-Referenz.

MCP-Server-Integration

Für die bestmögliche Agentenerfahrung nutzen Sie den gehosteten Didit-MCP-Server unter https://mcp.didit.me/mcp. Er benötigt keinen API-Schlüssel: Bei der ersten Verbindung öffnet Ihr Client einen Browser, Sie klicken auf Mit Didit anmelden (OAuth 2.1 mit PKCE) und der Server agiert in Ihrem Namen mit den Berechtigungen Ihrer Console-Rolle. Clients mit nativer Unterstützung für Remote-MCP (Cursor, VS Code) nutzen diesen Eintrag; Claude Web und Desktop fügen ihn als benutzerdefinierten Connector hinzu:
Claude Code: claude mcp add --transport http didit https://mcp.didit.me/mcp. Clients, die nur stdio unterstützen (Windsurf, Zed), nutzen die mcp-remote-Bridge, die den OAuth-Flow für Sie ausführt. Der API-Schlüssel, den Sie aus dem obigen Registrierungs-Flow erhalten, dient zum Aufrufen der REST-API von Ihrem eigenen Backend aus; der MCP verwendet ihn nie. Weitere Details finden Sie in der MCP-Übersicht und der Installation pro Client.

Referenz zur Fehlerstruktur

Alle apx.didit.me/auth/v2-Endpoints teilen sich dieselben drei Antwortstrukturen (siehe openapi-auth.json):
  • Validierung auf Feldebene — {"field": ["message", ...]} mit HTTP 400.
  • Validierung auf Formularebene (insbesondere Passwortstärke und Verifizierungscode-Fehler) — einfaches Array ["Invalid or expired verification code."] mit HTTP 400.
  • Authentifizierung / Geschäftsregel — {"detail": "..."} mit 400, 401, 403, 404 oder 429. 429-Antworten enthalten einen Retry-After-Response-Header, der angibt, wie lange Sie warten müssen (der Body enthält nur detail).
Der Verification-Host gibt Fehler als {"detail": "..."} zurück und 429-Antworten enthalten X-RateLimit-* und Retry-After – siehe Rate-Limits.
Zuletzt geändert am 7. November 2026