Authentifizierung
Alle Endpoints der Management-API verwenden Ihren API-Schlüssel der Anwendung. In den URLs sind keine Org- oder App-UUIDs erforderlich, da die Anwendung anhand Ihres Schlüssels identifiziert wird.Workflows
Workflows legen fest, welche Verifizierungsschritte Ihre Benutzer durchlaufen (Ausweis-Scan, Liveness-Erkennung, Gesichtsabgleich, AML-Screening usw.). Jeder Workflow ist eine wiederverwendbare Konfiguration, die Sie Sitzungen zuweisen.GET
Listet alle Workflows Ihrer Anwendung auf. Gibt die Funktionen, Schwellenwerte und die Information zurück, ob es sich um den Standard-Workflow handelt.
POST
Erstellt einen neuen Workflow. Legen Sie fest, welche Verifizierungsfunktionen aktiviert werden, setzen Sie Schwellenwerte, konfigurieren Sie akzeptierte Dokumenttypen und vieles mehr.
GET
Ruft alle Details eines bestimmten Workflows ab, einschließlich aller Funktionskonfigurationen und Schwellenwerte.
PATCH
Aktualisiert die Konfiguration eines Workflows. Sie können Funktionseinstellungen, Schwellenwerte oder akzeptierte Dokumente beliebig ändern.
DELETE
Löscht einen Workflow. Sitzungen, die diesen Workflow bereits verwenden, sind davon nicht betroffen.
Kurzbeispiel: Workflow erstellen
Derworkflow_type bestimmt den grundlegenden Funktionsumfang. Einzelne Funktionen werden anschließend mit den is_*_enabled-Flags aktiviert oder deaktiviert.
workflow_type-Werte: kyc, kyb, adaptive_age_verification, biometric_authentication, address_verification, questionnaire_verification, email_verification, phone_verification.
Bei kyc-Workflows ist die Ausweisverifizierung automatisch enthalten. Dafür brauchen Sie kein eigenes Flag. Mit den is_*_enabled-Flags fügen Sie optionale Funktionen wie Gesichtsabgleich, Liveness-Erkennung, AML, NFC, Telefon, E-Mail, Adressnachweis, Geräte- und IP-Analyse und weitere hinzu oder entfernen sie.
Verwenden Sie den Workflow anschließend beim Erstellen von Sitzungen:
Fragebögen
Benutzerdefinierte Formulare, die Sie Verifizierungs-Workflows hinzufügen können, um zusätzliche Informationen von Benutzern zu erfassen.GET
Listet alle Fragebögen auf.
POST
Erstellt einen neuen Fragebogen mit benutzerdefinierten Fragen, Verzweigungslogik und Übersetzungen.
GET
Ruft die Details eines Fragebogens ab, einschließlich aller Fragen und der Formularstruktur.
PATCH
Aktualisiert einen Fragebogen.
DELETE
Löscht einen Fragebogen.
Benutzer
Verwalten Sie verifizierte Personen (Benutzer) in Ihrer Anwendung. Jeder Benutzer wird über einenvendor_data-String identifiziert, den Sie beim Erstellen von Sitzungen angeben.
GET
Listet alle Benutzer Ihrer Anwendung auf, einschließlich ihres Verifizierungsstatus und ihres Sitzungsverlaufs.
GET
Ruft die Details eines Benutzers über Ihre vendor_data-Kennung ab.
PATCH
Aktualisiert die Metadaten eines Benutzers.
POST
Löscht Benutzer stapelweise. Anfragetext:
{"vendor_data_list": ["user-1", "user-2"]} oder {"delete_all": true}. Außerdem werden alle biometrischen Templates endgültig gelöscht, die für diese Benutzer aufbewahrt werden.Biometrische Templates
Bildfreie biometrische Gesichts-Templates, die eine Anwendung, die ihre Einwilligung erteilt hat, nach dem Löschen von Sitzungen aufbewahrt. Siehe Biometrische Templates.GET
Paginierte Liste mit Filtern (
vendor_data, vendor_user_uuid, status, source_type, retained_from, retained_to, ordering).GET
Zählt die Templates mit denselben Filtern.
GET
Ein Template: zugehöriger Benutzer, Herkunftsreferenz, Ablaufdatum, Anweisung und Status.
DELETE
Löscht ein Template endgültig. Gibt
{"uuid": "...", "outcome": "purged" | "already_purged"} zurück.POST
Endgültige Massenlöschung. Anfragetext:
{"template_uuids": [...]} oder {"delete_all": true} zusammen mit optionalen Filtern.Vorgänge für Sitzungen
POST
Löscht Sitzungen stapelweise. Erfordert
delete:sessions. Anfragetext: {"session_numbers": ["1", "2", "3"]} oder {"delete_all": true} (grenzen Sie delete_all mit den Filtern der Liste der Sitzungen ein, denen filter_ vorangestellt ist, z. B. filter_status), außerdem optional retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction und instruction_id. Bis zu 20 passende Sitzungen liefern 200 mit einem face_retention_outcome pro Sitzung zurück. Mehr Sitzungen liefern 202 mit einem Löschauftrag.GET
Fortschritt und Ergebniszahlen einer Massenlöschung von Sitzungen, die
202 zurückgegeben hat.GET
Listet die Prüfungen und das Aktivitätsprotokoll einer Sitzung auf.
POST
Fügt einer Sitzung eine Prüfnotiz oder eine Statusänderung hinzu.
Abrechnung
GET
Ruft das aktuelle Credit-Guthaben und die Einstellungen für die automatische Aufladung ab.
POST
Erstellt eine Stripe-Checkout-Sitzung zum Aufladen von Credits. Jede Aufladung beträgt $50 bis $20,000 und wird zum Nennwert gutgeschrieben.
Listen (Sperrlisten, Freigabelisten & benutzerdefinierte Listen)
Verwalten Sie typisierte Listen für Sperrung, Freigabe und benutzerdefinierte Workflow-Bedingungen. Weitere Informationen finden Sie in der vollständigen Lists-API-Dokumentation.GET
Listet alle Listen der Anwendung auf (Sperrlisten, Freigabelisten, benutzerdefinierte Listen).
POST
Fügt einer Liste einen Eintrag hinzu. Unterstützt
reference_session_id, um Daten aus einer Sitzung automatisch zu übernehmen, und reference_object_uuid zur Nachverfolgbarkeit von Transaktionen, Benutzern bzw. Unternehmen.DELETE
Entfernt einen Eintrag aus einer Liste.
POST
Lädt ein Gesichtsbild (Base64) in eine Gesichts-Sperrliste hoch.
Webhook-Konfiguration
GET
Ruft die aktuelle Webhook-Konfiguration ab, einschließlich URL, Version, des geheimen Schlüssels zur Überprüfung der Webhook-Signaturen sowie der Richtlinie zur Datenaufbewahrung und zur Aufbewahrung biometrischer Templates der Anwendung.
Die Antwort enthält außerdem
allowed_domains, das unten unter PATCH /v3/webhook/ beschrieben wird.PATCH
Aktualisiert die Webhook-URL und die Version oder rotiert den geheimen Schlüssel. Setzen Sie
rotate_secret_key: true, um ein neues Webhook-Geheimnis zu erzeugen; das alte wird sofort ungültig. Legt außerdem die Aufbewahrungsrichtlinie der Anwendung fest: data_retention_months sowie face_retention_policy (delete_with_session als Standard oder retain_until_user_deleted). Ist die Aufbewahrung aktiviert, ist zusätzlich ein endlicher Wert für face_retention_days (1–3650) erforderlich. Siehe Aufbewahrung biometrischer Templates. Registriert außerdem allowed_return_hosts: bis zu 20 reine Hostnamen (zum Beispiel app.example.com, ohne Schema, Port, Pfad oder Wildcard), zu denen eine Verifizierung über die Digital-ID-Wallet-API den Nutzer über HTTPS zurücksenden darf. Eine neue Liste ersetzt die bisher registrierte, und die White-Label-Domain Ihrer Anwendung ist immer erlaubt.Legt außerdem allowed_domains fest: bis zu 50 Web-Origins (zum Beispiel https://app.example.com), in die der gehostete Verifizierungsablauf eingebettet werden darf und zu denen er den Nutzer mit einem Sitzungs-callback zurücksenden darf.
Jeder Eintrag besteht aus einem Schema, einem Host und einem optionalen Port, ohne Pfad, Query oder Wildcard.
Verwenden Sie https; http ist nur für localhost, 127.0.0.1 und ::1 zulässig.
Didit speichert jeden Origin in Kleinbuchstaben ohne Standardport und gibt die Liste in allowed_domains zurück.
Ein ungültiger Eintrag führt bei allowed_domains zu einem 400-Fehler.
Eine neue Liste ersetzt die registrierte, und eine leere Liste hebt die Einschränkung auf.
Solange die Liste nicht leer ist, weist POST /v3/session/ einen Web-callback außerhalb der Liste mit 400 ab, und der gehostete Ablauf leitet den Nutzer nicht zu einem gespeicherten oder Workflow-standardmäßigen Callback außerhalb der Liste weiter.
Benutzerdefinierte URL-Schemas (App-Deep-Links) und serverseitige API-Aufrufe sind davon nicht betroffen.Wenn Sie endpoints senden, werden alle Webhook-Ziele, die die Liste auslässt, dauerhaft gelöscht, zusammen mit ihrem Signaturgeheimnis und ihrem gesamten Zustellungsprotokoll, genau wie bei DELETE /v3/webhook/destinations/{destination_uuid}/.
Dies kann nicht rückgängig gemacht werden.
Um Webhook-Ziele einzeln zu verwalten, verwenden Sie stattdessen die Endpoints für Webhook-Ziele.