Zum Hauptinhalt springen
PATCH
curl

Was dieser Endpoint bewirkt

Das AML-Screening liefert eine Liste von Treffern, also möglichen Übereinstimmungen mit Sanktionslisten, PEP-Datenbanken, Beobachtungslisten und negativen Medienberichten. Jeder Treffer hat ein review_status (seine Bewertung), das je nach Übereinstimmungswert als Unreviewed oder False Positive beginnt. Über diesen Endpoint kann Ihr Team (oder Ihre Automatisierung) für jeden Treffer eine Entscheidung festhalten, ohne die Gesamtentscheidung der Sitzung zu ändern. Die Treffer und ihre IDs finden Sie in der Sitzungsentscheidung, im Array hits der AML-Prüfung. Die id jedes Treffers ist die hit_id, die Sie hier übergeben. Eine Treffer-id besteht aus hit_ gefolgt von 24 hexadezimalen Zeichen und bleibt bei einer erneuten Prüfung der Person bzw. Entität gleich. Eine Treffer-ID im früheren Format wird weiterhin akzeptiert. Die Antwort nennt den Treffer immer über seine aktuelle id.

Prüfstatus

Entscheidungen der Prüfer bleiben bei erneuten Prüfungen im Rahmen der laufenden Überwachung erhalten. Ein Treffer, den Sie als False Positive markieren, behält diesen Status, wenn der Anbieter die Entität erneut prüft.

Einen einzelnen Treffer aktualisieren

PATCH /v3/session/{sessionId}/update-aml-hit-status/
Bei einer Sitzung mit mehreren AML-Prüfungen (Graph-Workflows) hängen Sie ?node_id=feature_aml_1 an die URL an oder fügen "node_id" in den Body ein, um eine bestimmte Prüfung anzusprechen.

Mehrere Treffer gleichzeitig aktualisieren

PATCH /v3/session/{sessionId}/bulk-update-aml-hit-status/ Übergeben Sie hit_updates, eine Liste von { hit_id, review_status }-Paaren. Der Vorgang folgt dem Alles-oder-nichts-Prinzip: Wenn eine hit_id nicht gefunden wird, gibt die Anfrage 404 zurück, und es wird kein Treffer geändert.
Ein erfolgreicher Bulk-Aufruf löst einen einzigen data.updated-Webhook aus und erfasst einen einzigen Aktivitätseintrag, der alle Änderungen umfasst.

Was nach einer Aktualisierung passiert

  • Webhook: Für die Sitzung wird ein Ereignis data.updated ausgelöst.
  • Prüfpfad: Die Änderung wird im Prüfpfad der Sitzung zusammen mit dem Akteur (API-Schlüssel oder Benutzer) erfasst und ist in der Aktivitäts-Timeline der Konsole sichtbar.
  • Der Gesamtstatus des AML-Schritts bleibt unverändert: Die Änderung der Bewertung eines Treffers ändert für sich genommen weder den Status des AML-Schritts noch die Entscheidung der Sitzung. Um den Status des AML-Schritts zu ändern (Approved / Declined / In Review), verwenden Sie Feature-Status aktualisieren. Um die Entscheidung der Sitzung zu ändern, verwenden Sie Status aktualisieren.

Unterstützung für KYC und KYB

Der Endpoint funktioniert sowohl für Benutzerverifizierung (KYC) als auch für Unternehmensverifizierung (KYB). Didit löst die sessionId in beiden Fällen auf. Bei KYB läuft das AML-Screening für das Unternehmen und seine Schlüsselpersonen, und jede AML-Prüfung stellt ihre eigenen Treffer bereit.

Berechtigung

Erforderlich ist die Berechtigung write:sessions, und zwar entweder mit einem Client-API-Schlüssel (x-api-key) oder mit einem Autorisierungs-Header für Benutzer.

Fehler

Verwandte Seiten

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 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"

Abfrageparameter

node_id
string

Workflow-Graph-Knoten-ID. Nur erforderlich, wenn die Sitzung mehrere AML-Prüfungen umfasst (eine pro Knoten); bei Sitzungen mit einer einzigen AML-Prüfung weglassen.

Beispiel:

"feature_aml_1"

Body

application/json
hit_id
string
erforderlich

Die id des Treffers im hits-Array der AML-Prüfung (hit_...). Eine Treffer-ID, die im früheren Format zurückgegeben wurde, wird weiterhin akzeptiert.

Beispiel:

"hit_7c1e9a40b2d35f86e0a4c912"

review_status
enum<string>
erforderlich

Der neue Prüfstatus für den Treffer.

Verfügbare Optionen:
Unreviewed,
Confirmed Match,
False Positive,
Inconclusive
Beispiel:

"False Positive"

node_id
string

Optionale Graph-Knoten-ID. Verwenden Sie diese (hier oder als Abfrageparameter), wenn die Sitzung mehrere AML-Prüfungen umfasst.

Beispiel:

"feature_aml_1"

Antwort

Hit-Prüfstatus aktualisiert.

message
string
erforderlich

Immer Hit status updated successfully.

hit_id
string
erforderlich

Die id des aktualisierten Treffers, wie von der Sitzungsentscheidung zurückgegeben, auch wenn die Anfrage den Treffer über eine ID im früheren Format benannt hat.

review_status
enum<string>
erforderlich

Der Prüfstatus, der jetzt für den Treffer gespeichert ist.

Verfügbare Optionen:
Unreviewed,
Confirmed Match,
False Positive,
Inconclusive
Zuletzt geändert am 7. November 2026