Zum Hauptinhalt springen
Die Server-SDKs sind die offiziellen Didit-Bibliotheken für Ihr Backend. Jedes SDK ruft die Server-Endpoints der API-Referenz mit typisierten Anfragen und Antworten auf, verifiziert die Webhooks, die Didit an Sie sendet, und überprüft die Token von Didit Authentication. In Version 1.0.1 sind die beiden Google-Wallet-Endpoints noch in keinem Release enthalten: eine Google-Wallet-Verifizierung starten und eine Wallet-Antwort übermitteln. Die SDKs für Python, Node.js, Java, PHP, Ruby und .NET enthalten alle anderen Server-Endpoints. In Go 1.0.1 fehlen zudem neun weitere Endpoints, größtenteils für die Travel Rule: siehe Noch nicht im Go-SDK enthaltene Endpoints. Verwenden Sie sie überall dort, wo Ihr Code einen Didit-API-Schlüssel enthält: beim Erstellen von Verifizierungssitzungen, Abrufen von Entscheidungen, Aufrufen der eigenständigen APIs, Verwalten von Benutzern, Unternehmen, Workflows und Fällen sowie beim Screenen von Transaktionen und Wallets und für die Travel Rule. Verwenden Sie im Browser oder in einer mobilen App stattdessen die Web- und Native-SDKs: Sie präsentieren den Verifizierungsablauf Ihren Benutzern und enthalten zu keinem Zeitpunkt Ihren API-Schlüssel. Die Seiten der Server-Endpoints in der API-Referenz, einschließlich der Seiten für die Datenbankvalidierung, zeigen für jedes Server-SDK ein Codebeispiel neben der cURL-Anfrage. Ein Beispiel wird angezeigt, sobald das neueste Release des SDKs den Endpoint und alle im Beispiel gesendeten Felder enthält: Wird der API ein Endpoint oder ein Feld hinzugefügt, werden die entsprechenden Beispiele mit dem nächsten Release des jeweiligen SDKs bereitgestellt. In Version 1.0.1 ist keines der 16 nach der Generierung hinzugefügten Anfragefelder der Datenbankvalidierung (wie vin oder bank_account_number) enthalten, weshalb auf den entsprechenden Dienstseiten ausschließlich cURL angezeigt wird.

​
Installieren

​
Konfigurieren

Jedes SDK liest dieselben Umgebungsvariablen aus, sodass ein ohne Optionen erstellter Client sofort einsatzbereit ist. Edge-Laufzeitumgebungen verfügen über keine Prozessumgebung: Übergeben Sie den API-Schlüssel dem Node.js-Client dort als Option. Alles, was Sie über die Umgebung festlegen können, lässt sich auch an den Client übergeben – zusammen mit der Basis-URL, dem Timeout, Wiederholungsversuchen, Standard-Headern und Ihrem eigenen HTTP-Client. Erstellen Sie einen Client pro Prozess und teilen Sie ihn: Er verwaltet einen Connection-Pool und kann sicher über mehrere Threads oder Tasks hinweg verwendet werden. Die account-Methoden (programmatische Registrierung: Registrieren, Anmelden, Organisationen und Anwendungen) rufen https://apx.didit.me/auth/v2 auf und senden Ihren API-Schlüssel zu keinem Zeitpunkt. Melden Sie sich mit account.login an und übergeben Sie das zurückgegebene Access-Token anschließend als Account-Token an den Client.

​
Was jedes SDK bietet

  • Ressourcen und Methoden. Aufrufe folgen den Ressourcen der API: client.<resource>.<method>(...), beispielsweise sessions.create, sessions.retrieve_decision oder transactions.create, in der jeweiligen Schreibweise der Sprache. Pfad-IDs sind Positionsargumente; Body und Query bilden eine Gruppe benannter Felder. Python, Node.js, PHP und Ruby verwenden die API-eigenen Feldnamen (workflow_id); Go, Java und .NET nutzen die Konventionen ihrer jeweiligen Sprache (WorkflowID, workflowId, WorkflowId).
  • Listen. Listenmethoden paginieren automatisch durch alle Ergebnisse für Sie (unter Verwendung von limit und offset) und stellen zudem jede Seite mit count, next, previous und results bereit. In Ruby iteriert auto_paging_each durch jede Seite, wobei total_count, next_url und previous_url einer Seite den Feldern count, next und previous der API entsprechen.
  • Dateien. Uploads (Dokumentbilder, Selfies, Adressnachweise, Importe) akzeptieren einen Pfad, Bytes oder einen Stream. Downloads (Sitzungs-PDFs, Berichte) geben Bytes oder einen Stream zurück, niemals geparstes JSON.
  • Vorwärtskompatibilität. Ein Antwortfeld oder ein Enum-Wert, den die SDK-Version noch nicht kennt, wird beibehalten und bleibt lesbar, ohne einen Fehler auszulösen. So führt eine API-Erweiterung nicht zu Problemen in einer produktiven Integration.
  • Webhooks. webhooks.verify prüft die Header X-Signature-V2 und X-Signature sowie den Zeitstempel einer Zustellung anhand Ihres Webhook-Secrets und gibt ein typisiertes Ereignis zurück. Es akzeptiert eine Liste von Secrets, während Sie ein Secret rotieren. Das Signaturschema finden Sie unter Webhooks.
  • Authentifizierung. Ein Authentication-Helper verifiziert die Access- und ID-Token, die der Aussteller Ihrer Authentication signiert, und ruft dessen Token-, Sitzungs- und Step-up-Endpoints auf. Er verwendet Ihren API-Schlüssel zu keinem Zeitpunkt.

​
Fehler, Wiederholungsversuche und Timeouts

Jeder Fehler leitet sich von DiditError ab. In Go implementiert jeder Fehler das didit.Error-Interface und ist ein Zeigertyp wie *didit.NotFoundError. Java, PHP und .NET benennen sie mit ihrem üblichen Exception-Suffix und schreiben API als Api: DiditException, ApiStatusException, NotFoundException. Die SDKs wiederholen eine fehlgeschlagene Anfrage bis zu 2-mal mit exponentiellem Backoff ab 0,5 Sekunden (Full Jitter, maximal 8 Sekunden) und unter Berücksichtigung von Retry-After. GET, HEAD, PUT und DELETE werden bei Verbindungsfehlern, Timeouts, 408, 429 und 5xx wiederholt. POST und PATCH werden nur bei 429 wiederholt oder wenn die Verbindung vor dem Senden der Anfrage fehlgeschlagen ist, sodass ein Wiederholungsversuch niemals eine zweite Sitzung oder Transaktion erstellt. Das Standard-Timeout beträgt 60 Sekunden. Jede Antwort gibt außerdem den rohen HTTP-Status, die Header und die Request-ID zurück. Siehe Rate-Limiting für die Grenzwerte hinter 429.

​
Versionierung und Support

  • Die SDKs folgen semantischer Versionierung mit einer Regel für API-Änderungen. Eine Änderung, die die Didit-API widerspiegelt, ist ein Minor-Release, selbst wenn sie zu Fehlern in typisiertem Code führen kann (ein Feld, dessen Typ sich geändert hat, ein Feld, das jetzt null sein kann, oder ein entfernter Endpoint, ein entferntes Feld oder ein entfernter Enum-Wert): Die API verhält sich für jeden Aufrufer bereits so, daher ist eine ältere SDK-Version nicht sicherer. In den Release Notes werden solche Änderungen unter „API changes that can break typed code“ aufgeführt.
  • Eine Major-Version gibt es nur bei einer Änderung am Design des SDKs selbst: eine Methode oder Ressource wird umbenannt oder entfernt, während die API sie beibehält, eine Änderung an der Client-Konfiguration, an Fehlern, Wiederholungsversuchen, Paginierung oder dem Verhalten der Webhook-Verifizierung oder eine nicht mehr unterstützte Laufzeitversion. Wenn ein Endpoint die API verlässt oder seine Methode umbenannt wird, bleibt die alte Methode für mindestens eine weitere Minor-Version als veraltet markiert bestehen, sodass Ihr Code weiterhin gebaut werden kann, während Sie zur neuen Methode wechseln. Jede Sprache behält ihre eigene Versionsnummer: Node.js, PHP und Ruby sind bei 2.x und die anderen bei 1.x, da diese drei eine API-Änderung als Major-Version veröffentlicht haben, bevor diese Regel galt.
  • Sie werden aus dem veröffentlichten API-Vertrag (openapi-25.json und openapi-auth.json) generiert, und ihre Didit Authentication-Methoden werden anhand von openapi-authentication.json überprüft. Alle drei werden täglich geprüft, sodass ein neuer Endpoint oder ein neues Feld in einem regulären Release aller sieben SDKs verfügbar wird.
  • Jedes SDK unterstützt die in der Tabelle angegebene Mindestversion der Laufzeit und jedes neuere Release. Seine Tests laufen auf der Mindestversion und auf jedem neueren Release bzw. auf jeder Long-Term-Support-Version für Node.js und Java.
  • Das CHANGELOG.md jedes Repositorys führt die Änderungen jedes Releases auf.
  • Melden Sie ein Sicherheitsproblem vertraulich über die Sicherheitsmeldungen des jeweiligen SDK-Repositorys oder an support@didit.me.
Zuletzt geändert am 7. November 2026