Zum Hauptinhalt springen
PATCH
curl

KYC- und KYB-Unterstützung

Dieser Endpoint funktioniert für Sitzungen der Benutzerverifizierung (KYC) und der Unternehmensverifizierung (KYB) identisch. Didit gleicht die session_id mit beiden Sitzungsarten ab. Die Validierung der Statusübergänge ist für beide gleich, da dieselbe Statusaufzählung für beide gilt. Die Antwort enthält nur die session_id. Lesen Sie session_kind aus Session abrufen aus, wenn Ihre nachgelagerte Logik je nach Art der Sitzung unterscheiden muss.

Erlaubte Übergänge

Sie können eine Sitzung auf Approved, Declined oder Resubmitted setzen. Jeder andere new_status, einschließlich In Review, gibt 400 zurück. Der aktuelle Status der Sitzung muss einer der folgenden sein: Approved, Declined, In Review, Kyc Expired, Abandoned oder Resubmitted. Andernfalls gibt die API 400 zurück. Das Setzen von Approved oder Declined auf eine Sitzung, die bereits diesen Status hat, bleibt ohne Wirkung: Die API gibt 200 zurück, ändert nichts, löst keinen Webhook aus und sendet keine E-Mail. Das Setzen von Resubmitted auf eine Sitzung, die bereits Resubmitted ist, gibt 400 zurück (The new status is the same as the current status.). Eine erneute Einreichung, deren nodes_to_resubmit nur reine Backend-Features enthalten (AML, DATABASE_VALIDATION, IP_ANALYSIS), wird automatisch ausgeführt und setzt die Sitzung ohne Benutzerinteraktion in einen entschiedenen Status zurück. Wiederholen Sie eine solche erneute Einreichung innerhalb von 30 Sekunden, gibt sie 429 Too Many Requests mit einem Retry-After-Header zurück, da eine sofortige Wiederholung kein anderes Ergebnis liefern kann. Lösen Sie keine automatische erneute Einreichung aus einem Webhook-Handler aus, wenn Sie einen In Review-Status erhalten. Prüfen Sie zuerst den Befund oder ändern Sie die zugrunde liegenden Daten.

Die E-Mail vorab prüfen

Mit send_email: true senden Approved und Declined der Person ihre Entscheidungs-E-Mail, und Resubmitted schickt ihr einen neuen Link mit den Gründen. Sie können diese E-Mail sehen, bevor Sie etwas ändern:
  1. Rufen Sie Entscheidungs-E-Mail-Vorschau für Approved oder Declined auf oder Vorschau der E-Mail zur erneuten Einreichung für Resubmitted.
  2. Prüfen Sie den gerenderten subject und html, den recipient sowie will_be_sent / not_sent_reason.
  3. Rufen Sie diesen Endpoint mit demselben new_status auf (und bei einer erneuten Einreichung mit denselben nodes_to_resubmit), mit send_email: true, email_address auf den Wert von recipient gesetzt, der in der Vorschau verwendeten email_language und email_preview_token auf den Wert von preview_token gesetzt.
Keine der beiden Vorschauen verändert die Sitzung oder versendet etwas. Das Update sendet danach genau die E-Mail, die Sie vorab gesehen haben. Der Beleg läuft nach 15 Minuten ab. Haben sich Empfänger, Sprache, Sitzungsstatus, Absender oder E-Mail seit der Vorschau geändert, gibt das Update 409 zurück, bevor etwas verändert wird. Erstellen Sie dann die Vorschau erneut und bestätigen Sie mit dem neuen Beleg. Das Senden von email_preview_token ohne send_email: true gibt 400 zurück. Der Vorschau-Schritt ist optional: Bestehende Integrationen können diesen Endpoint weiterhin ohne ihn aufrufen.

Beispiele

Berechtigung

Erfordert die Berechtigung write:sessions. Dieselbe Berechtigung gilt für beide Arten.

Verwandte Themen

Autorisierungen

x-api-key
string
header
erforderlich

Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys.

Pfadparameter

sessionId
string<uuid>
erforderlich

UUID der zu aktualisierenden Verifizierungssitzung. Akzeptiert sowohl Benutzer- (KYC) als auch Unternehmens- (KYB) Sitzungs-IDs — der Dienst löst die ID über beide Sitzungstypen hinweg auf.

Beispiel:

"11111111-2222-3333-4444-555555555555"

Body

application/json
new_status
enum<string>
erforderlich

Zielstatus. Approved und Declined erfassen eine endgültige manuelle Entscheidung (jede kann auch die andere aufheben). Resubmitted setzt die ausgewählten Schritte zurück und sendet die Sitzung an den Benutzer zurück. Jeder andere Wert gibt 400 zurück.

Verfügbare Optionen:
Approved,
Declined,
Resubmitted
Beispiel:

"Approved"

comment
string

Freitext-Begründung für die Änderung, gespeichert im Prüfpfad der Sitzung und zurückgegeben im Array reviews von Get Decision. Zum Beispiel Duplicated user.

Beispiel:

"All checks passed manual review"

nodes_to_resubmit
object[]

Workflow-Schritte, die der Benutzer wiederholen muss. Wird nur verarbeitet, wenn new_status den Wert Resubmitted hat. Für Approved/Declined werden die Einträge dennoch schemavalidiert (ein ungültiger feature-Wert gibt 400 zurück), aber schemagültige Einträge werden semantisch ignoriert. Wenn weggelassen, wählt der Server automatisch bestehende OCR-, Liveness-, Gesichtsabgleich-, POA-, Telefon-, E-Mail-, AML-, Datenbankvalidierungs- und Fragebogen-Versuche aus, deren Status Declined, In Review, Not Finished oder Expired lautet (NFC-, IP-Analyse-, Altersschätzungs-, Gesichtssuch- und KYB-Dokument-Versuche werden nie automatisch ausgewählt; Gesichtsversuche ohne Gesichtsabgleich werden als LIVENESS ausgewählt) — Funktionen, die der Benutzer nie versucht hat (kein erfasster Versuch), werden NICHT ausgewählt, sodass eine Sitzung mit null Versuchen 400 zurückgibt ("No features found that need resubmission"), obwohl nichts genehmigt wurde; übergeben Sie in diesem Fall nodes_to_resubmit explizit. Die Schritte werden in der Reihenfolge des Workflow-Graphen ausgeführt, unabhängig von der Reihenfolge, in der Sie sie senden. KYB_REGISTRY, KYB_KEY_PEOPLE und der KYB-Alias werden mit 400 abgelehnt — diese übergeordneten Prüfungen werden aus ihren untergeordneten KYC-Sitzungen neu berechnet.

send_email
boolean
Standard:false

Gibt an, ob der Benutzer per E-Mail über die Änderung benachrichtigt werden soll. Erfordert email_address. Bei Approved/Declined erhält der Benutzer eine Statusbenachrichtigung; bei Resubmitted enthält die E-Mail den Verifizierungslink und die Gründe für die erneute Einreichung pro Schritt.

Beispiel:

false

email_address
string<email>

Empfänger für die Benachrichtigungs-E-Mail. Erforderlich, wenn send_email den Wert true hat – das Weglassen gibt 400 zurück.

Beispiel:

"user@example.com"

email_language
string
Standard:en

Sprache für die Benachrichtigungs-E-Mail. Akzeptiert auf Schemaebene beliebige Zeichenketten; bei nicht unterstützten Codes wird stillschweigend auf Englisch (en) zurückgegriffen.

Beispiel:

"en"

email_preview_token
string
write-only

Optionaler Beleg aus Vorschau der Entscheidungs-E-Mail (für Approved und Declined) oder Vorschau der E-Mail zur erneuten Einreichung (für Resubmitted): dessen preview_token. Nur gültig mit send_email: true; ohne dieses Attribut gibt die Anfrage 400 zurück. Empfänger, Sprache, Sitzungsstatus, Absender und E-Mail (sowie bei einer erneuten Einreichung die ausgewählten Schritte) müssen weiterhin mit der Vorschau übereinstimmen, und der Beleg läuft nach 15 Minuten ab. Andernfalls gibt die Anfrage 409 zurück, bevor die Sitzung geändert oder eine E-Mail gesendet wird. Bestehende Integrationen können dieses Feld weglassen.

Required string length: 1 - 512

Antwort

Status aktualisiert. Die Antwort enthält nur die session_id; rufen Sie die aktualisierte Sitzung über Get Decision ab. Der status.updated-Webhook wird ausgelöst, sobald die Änderung übernommen wurde. Das Wiederholen von Approved oder Declined gibt denselben Body zurück und ändert nichts.

session_id
string<uuid>

UUID der aktualisierten Sitzung.

Zuletzt geändert am 7. November 2026