Passer au contenu principal
POST
curl

Présentation

Active ou désactive la surveillance AML continue pour les entités utilisateur sélectionnées, exactement comme l’action Surveillance AML continue dans la Business Console. La Console et cet endpoint exécutent la même opération sous-jacente : les règles, la facturation et les résultats sont identiques. Envoyez d’abord estimate_only: true pour connaître le nombre d’utilisateurs sélectionnés, le nombre de ceux qui nécessitent un nouveau filtrage AML, le coût unique du filtrage et le coût annuel de la surveillance. Un essai à blanc n’écrit rien.

Quand l’utiliser

  • Onboarding programmatique : activez la surveillance pour les utilisateurs que vous avez importés ou créés via l’API, sans les filtrer à nouveau manuellement.
  • Offboarding : arrêtez la surveillance, ainsi que son renouvellement annuel, pour les utilisateurs qui ont quitté votre plateforme.
  • Maîtrise des coûts : prévisualisez l’impact exact sur les coûts d’une sélection avant de vous engager.

Traitement d’une sélection

  • Un filtrage surveillé par utilisateur. Un utilisateur qui a effectué plusieurs vérifications est surveillé et facturé une seule fois. La désactivation arrête la surveillance sur l’ensemble des filtrages de cet utilisateur.
  • Les utilisateurs sans filtrage AML sont filtrés en premier. Didit crée une nouvelle vérification AML pour eux (visible dans l’onglet Vérifications de l’utilisateur), facturée comme un filtrage AML classique, puis y active la surveillance. Cela nécessite le nom complet, la date de naissance et le pays de l’utilisateur ; un utilisateur auquel il manque l’un de ces éléments est signalé avec skipped_no_identity_data au lieu d’être ignoré silencieusement.
  • Les utilisateurs bloqués sont ignorés (skipped_blocked). Les applications sandbox ne créent jamais de filtrage (skipped_sandbox).
  • Le solde est vérifié au préalable. L’activation est refusée avec 403 si votre solde ne couvre pas l’estimation. La réponse contient alors l’estimation, afin que vous sachiez quel montant recharger.
  • Renouvellement annuel. Un utilisateur nouvellement surveillé est facturé au prix annuel de la surveillance à sa prochaine date de renouvellement, celle qui s’affiche dans la colonne Surveillance continue de la Console. La désactivation arrête le renouvellement ; elle ne rembourse pas une période déjà facturée.

Sélection et taille des lots

Sélectionnez les utilisateurs avec vendor_data_list, didit_internal_id_list, ou les deux ; les deux listes sont combinées par OU logique. Une requête accepte au maximum 1000 identifiants au total sur les deux listes. Les identifiants qui ne correspondent à aucun utilisateur de votre application sont renvoyés sous unmatched, tels qu’envoyés, et ne font jamais échouer la requête : une sélection sans correspondance se termine comme une tâche vide (total: 0) avec tous les identifiants listés, selon la même convention que les endpoints de suppression par lot.

Traitement synchrone ou en arrière-plan

Les sélections de 20 utilisateurs ou moins sont traitées immédiatement, et l’appel renvoie 200 avec la tâche terminée. Les sélections plus importantes renvoient 202 avec une tâche PENDING ; interrogez Obtenir la tâche de surveillance AML jusqu’à ce que status soit COMPLETED ou FAILED. Dans les deux cas, la tâche contient une entrée results par utilisateur, avec son outcome.

Webhooks

L’activation ou la désactivation de la surveillance n’émet aucun webhook propre. Une fois la surveillance active, les revérifications continuent de déclencher les événements habituels status.updated et data.updated décrits dans Surveillance AML continue.

Autorisations

Toute clé API active de l’application peut appeler cet endpoint. Les clés API de Didit sont limitées à l’application, et non à un rôle : les rôles et autorisations de la Console déterminent ce qu’une personne peut faire dans la Console et ne sont pas évalués pour le trafic de l’API de gestion.

Voir aussi

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.

Corps

application/json

Sélectionnez des utilisateurs avec vendor_data_list, didit_internal_id_list, ou les deux (les deux listes sont combinées avec un opérateur OU). Au maximum 1000 identifiants par requête sur l'ensemble des deux listes.

is_enabled
boolean
requis

true pour activer la surveillance, false pour la désactiver.

estimate_only
boolean
défaut:false

Si true, renvoie l'estimation des coûts et n'effectue aucune écriture : aucun filtrage, aucune facturation, aucune tâche.

vendor_data_list
string[]

Vos propres identifiants des utilisateurs à basculer, mis en correspondance exacte avec ceux transmis.

didit_internal_id_list
string<uuid>[]

Identifiants internes Didit des utilisateurs à basculer - le didit_internal_id renvoyé par les endpoints de création, d'obtention et de liste.

Réponse

L'estimation (lorsque estimate_only est true) ou la tâche terminée pour une sélection traitée en ligne.

Aperçu du coût. Renvoyé directement lorsque estimate_only est vrai (rien n'est écrit).

users_total
integer
requis

Profils correspondant à la sélection.

already_enabled
integer
requis

Profils déjà surveillés (aucune action lors de l'activation ; ce sont ceux que la désactivation désactive).

with_existing_aml
integer
requis

Profils dont le filtrage AML existant passera en mode surveillé (aucun nouveau filtrage).

needing_screening
integer
requis

Profils sans aucun filtrage AML qui seront d'abord filtrés (facturés comme un filtrage AML standard).

skipped_no_identity_data
integer
requis

Profils ne pouvant pas faire l'objet d'un filtrage en raison de données d'identité manquantes.

skipped_blocked
integer
requis

Utilisateurs bloqués qui seront ignorés (toujours 0 pour les entreprises).

estimated_screening_cost_usd
number
requis

Coût ponctuel des nouveaux filtrages.

Exemple:

0.2

estimated_annual_monitoring_cost_usd
number
requis

Coût de surveillance annuel des profils qui deviendront surveillés.

Exemple:

0.07

balance_sufficient
boolean
requis

Indique si le solde de l'organisation couvre le filtrage ainsi que la première année de surveillance.

unmatched
string[]
requis

Identifiants de la requête ne correspondant à aucun profil dans cette application, exactement tels qu'envoyés.

Dernière modification le 7 novembre 2026