Passer au contenu principal
PATCH
curl

Ce que fait cet endpoint

Le filtrage AML renvoie une liste de hits : des correspondances potentielles avec des listes de sanctions, des bases de PEP, des listes de surveillance et de la presse négative. Chaque hit possède un review_status (sa décision) qui commence à Unreviewed ou à False Positive, selon le score de correspondance. Cet endpoint permet à votre équipe (ou à votre automatisation) d’enregistrer une décision sur chaque hit, sans modifier la décision globale de la session. Vous trouverez les hits et leurs identifiants dans la décision de la session : le tableau hits de la vérification AML, où le id de chaque hit correspond au hit_id que vous transmettez ici. L’id d’un hit est constitué de hit_ suivi de 24 caractères hexadécimaux. Il reste le même lorsque la personne est de nouveau contrôlée. Un identifiant de hit au format précédent est toujours accepté : la réponse indique toujours le hit par son id actuel.

Statuts de revue

Les décisions des réviseurs sont conservées lors des nouveaux filtrages de la surveillance continue : un hit que vous marquez False Positive conserve ce statut lorsque le fournisseur relance le filtrage de l’entité.

Mettre à jour un seul hit

PATCH /v3/session/{sessionId}/update-aml-hit-status/
Pour une session comportant plusieurs vérifications AML (workflows en graphe), ajoutez ?node_id=feature_aml_1 à l’URL ou incluez "node_id" dans le corps de la requête pour cibler une vérification précise.

Mettre à jour plusieurs hits en une fois

PATCH /v3/session/{sessionId}/bulk-update-aml-hit-status/ Transmettez hit_updates, une liste de paires { hit_id, review_status }. L’opération est tout ou rien : si un hit_id est introuvable, la requête renvoie 404 et aucun hit n’est modifié.
Un appel groupé réussi déclenche un seul webhook data.updated et enregistre une seule entrée d’activité couvrant l’ensemble des modifications.

Ce qui se passe après une mise à jour

  • Webhook : un événement data.updated est déclenché sur la session.
  • Piste d’audit : la modification est enregistrée dans la piste de revue de la session, avec l’auteur (clé API ou utilisateur), visible dans la chronologie d’activité de la console.
  • Le statut global de l’étape AML ne change pas : modifier la décision d’un hit ne modifie pas, à lui seul, le statut de l’étape AML ni la décision de la session. Pour changer le statut de l’étape AML (Approved, Declined ou In Review), utilisez update-feature-status. Pour changer la décision de la session, utilisez update-status.

Prise en charge KYC et KYB

Cet endpoint fonctionne pour les sessions Vérification des utilisateurs (KYC) et Vérification d’entreprise (KYB) : Didit retrouve le sessionId dans les deux cas. Pour le KYB, le filtrage AML porte sur l’entreprise et sur ses personnes clés ; chaque vérification AML expose ses propres hits.

Autorisation

Requiert le privilège write:sessions, avec une clé API client (x-api-key) ou un en-tête d’autorisation utilisateur.

Erreurs

Liens connexes

Autorisations

x-api-key
string
header
requis

La clé API de votre application, issue de Développeurs -> Clés API dans la Business Console. La clé principale dispose d'un accès complet. Une clé nommée peut être restreinte : aucun, lecture ou écriture par ressource, limitée à certains workflows ou aux sessions approuvées, à une liste d'adresses IP et à une date d'expiration. 401 signifie que la clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a été envoyée, que la clé n'a pas accès à cette ressource ou action, ou que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur une route de session signifie que la session est hors des workflows ou des statuts de la clé. Une clé sans accès aux médias reçoit les URL d'images, de vidéos et de PDF à null, et une clé sans accès en écriture aux sessions reçoit les liens et tokens de session à null. Voir https://docs.didit.me/console/api-keys.

Paramètres de chemin

sessionId
string<uuid>
requis

UUID de la session de vérification. Accepte les identifiants de session d'utilisateur (KYC) et d'entreprise (KYB) — le service résout l'identifiant pour les deux types de session.

Exemple:

"11111111-2222-3333-4444-555555555555"

Paramètres de requête

node_id
string

ID de nœud du graphe de workflow. Requis uniquement lorsque la session comporte plusieurs contrôles AML (un par nœud) ; omettez-le pour les sessions avec un seul contrôle AML.

Exemple:

"feature_aml_1"

Corps

application/json
hit_id
string
requis

L'id du résultat dans le tableau hits du contrôle AML (hit_...). Un identifiant de résultat renvoyé dans l'ancien format est toujours accepté.

Exemple:

"hit_7c1e9a40b2d35f86e0a4c912"

review_status
enum<string>
requis

Le nouveau statut d'examen pour la correspondance.

Options disponibles:
Unreviewed,
Confirmed Match,
False Positive,
Inconclusive
Exemple:

"False Positive"

node_id
string

Identifiant de nœud de graphe optionnel. Utilisez-le (ici ou comme paramètre de requête) lorsque la session comporte plusieurs vérifications AML.

Exemple:

"feature_aml_1"

Réponse

Statut d'examen des correspondances mis à jour.

message
string
requis

Toujours Hit status updated successfully.

hit_id
string
requis

L'id du résultat mis à jour, tel que renvoyé par la décision de session, y compris lorsque la requête a désigné le résultat par un identifiant à l'ancien format.

review_status
enum<string>
requis

Le statut d'examen désormais enregistré sur la correspondance.

Options disponibles:
Unreviewed,
Confirmed Match,
False Positive,
Inconclusive
Dernière modification le 7 novembre 2026