Skip to main content
POST
curl

Overview

Enables or disables ongoing AML monitoring for the selected User entities, exactly as the AML Ongoing monitoring action in the Business Console does. The Console and this endpoint run the same underlying operation, so the rules, the billing and the outcomes are identical. Send estimate_only: true first to see how many users are selected, how many need a new AML screening, the one-time screening cost and the yearly monitoring cost. Nothing is written by a dry-run.

When to use it

  • Programmatic onboarding: turn monitoring on for users you imported or created through the API without re-screening them by hand.
  • Offboarding: stop monitoring, and its yearly renewal, for users who left your platform.
  • Cost control: preview the exact cost impact of a selection before committing to it.

How a selection is processed

  • One monitored screening per user. A user who verified several times is monitored and billed once. Disabling turns monitoring off across all of that user’s screenings.
  • Users without an AML screening are screened first. Didit creates a new AML verification for them (visible in the user’s Verifications tab), billed as a regular AML screening, and enables monitoring on it. This needs the user’s full name, date of birth and country; a user missing any of them is reported as skipped_no_identity_data rather than silently dropped.
  • Blocked users are skipped (skipped_blocked). Sandbox applications never create screenings (skipped_sandbox).
  • Balance is checked up front. Enabling is refused with 403 when your balance does not cover the estimate, and the response carries the estimate so you know how much to top up.
  • Yearly renewal. A newly monitored user is billed the yearly monitoring price at their next renewal date, the same date the Console shows in the Ongoing monitoring column. Disabling stops the renewal; it does not refund a period already billed.

Selection and batch size

Select users with vendor_data_list, didit_internal_id_list, or both; the two lists are OR’d. A request accepts at most 1000 identifiers across both lists. Identifiers that match no user in your application are returned under unmatched, exactly as sent, and never fail the request: a selection that matches nothing completes as an empty job (total: 0) with every identifier listed, the same convention as the batch delete endpoints.

Inline or in the background

Selections of 20 users or fewer are processed inline and the call returns 200 with the finished job. Larger selections return 202 with a PENDING job; poll Get AML Monitoring Job until status is COMPLETED or FAILED. Either way the job carries one results entry per user with its outcome.

Webhooks

Toggling monitoring emits no webhook of its own. Once monitoring is on, re-screens keep firing the usual status.updated and data.updated events described in Continuous AML Monitoring.

Permissions

Any active API key of the application can call this endpoint. Didit API keys are application-scoped, not role-scoped: the Console’s roles and permissions decide what a person can do in the Console and are not evaluated for Management API traffic.

Authorizations

x-api-key
string
header
required

Body

application/json

Select users with vendor_data_list, didit_internal_id_list, or both (the two lists are OR'd). At most 1000 identifiers per request across both lists.

is_enabled
boolean
required

true to enable monitoring, false to disable it.

estimate_only
boolean
default:false

When true, returns the cost estimate and performs no writes - no screening, no billing, no job.

vendor_data_list
string[]

Your own identifiers of the users to toggle, matched exactly as sent.

didit_internal_id_list
string<uuid>[]

Didit internal ids of the users to toggle - the didit_internal_id returned by the create, get and list endpoints.

Response

The estimate (when estimate_only is true) or the completed job for a selection processed inline.

Cost preview. Returned directly when estimate_only is true (nothing is written).

users_total
integer
required

Profiles matched by the selection.

already_enabled
integer
required

Profiles already monitored (nothing to do when enabling; these are what disabling turns off).

with_existing_aml
integer
required

Profiles whose existing AML screening will be switched to monitored (no new screening).

needing_screening
integer
required

Profiles without any AML screening that will be screened first (billed as a regular AML screening).

skipped_no_identity_data
integer
required

Profiles that cannot be screened because identity data is missing.

skipped_blocked
integer
required

Blocked users that will be skipped (always 0 for businesses).

estimated_screening_cost_usd
number
required

One-time cost of the new screenings.

Example:

0.2

estimated_annual_monitoring_cost_usd
number
required

Yearly monitoring cost of the profiles that will become monitored.

Example:

0.07

balance_sufficient
boolean
required

Whether the organization balance covers the screening plus the first year of monitoring.

unmatched
string[]
required

Identifiers of the request that matched no profile in this application, exactly as sent.