Ü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_keyin 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.
Basis-URL
Alle Endpoints in diesem Leitfaden befinden sich auf dem Auth-Host: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
Schritt 1: Registrieren
201 Created):
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
200 OK):
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: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 eine429-Antwort auslösen; der Retry-After-Response-Header gibt an, wie lange Sie warten müssen.
Ein
429-Body sieht wie folgt aus:
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 eigeneclient_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.
403.
Was können Agenten nach der Registrierung tun?
Mit demapi_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 unterhttps://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 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
Alleapx.didit.me/auth/v2-Endpoints teilen sich dieselben drei Antwortstrukturen (siehe openapi-auth.json):
- Validierung auf Feldebene —
{"field": ["message", ...]}mit HTTP400. - Validierung auf Formularebene (insbesondere Passwortstärke und Verifizierungscode-Fehler) — einfaches Array
["Invalid or expired verification code."]mit HTTP400. - Authentifizierung / Geschäftsregel —
{"detail": "..."}mit400,401,403,404oder429.429-Antworten enthalten einenRetry-After-Response-Header, der angibt, wie lange Sie warten müssen (der Body enthält nurdetail).
{"detail": "..."} zurück und 429-Antworten enthalten X-RateLimit-* und Retry-After – siehe Rate-Limits.