> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # List AML Screening History > List every ongoing AML monitoring re-screen of a session, including runs where nothing changed, with outcome, score and dataset freshness. List AML Screening History API Prompt Copy prompt to clipboard 
  \`List the ongoing AML monitoring history of one Didit verification session through the API.

  Endpoint:
  GET [https://verification.didit.me/v3/session/\{session\_id}/aml-screening-history/](https://verification.didit.me/v3/session/\{session_id}/aml-screening-history/)

  Authentication:
  Send my Didit API key in the x-api-key header. A scoped key needs decisions: read.

  Goal:

  * Prove that ongoing AML monitoring ran for a subject, including the re-screens that found nothing new, for example to answer an auditor.

  Query parameters:

  * node\_id (optional): the workflow node ID of the AML check when the session ran several AML steps. Without it, the most recent AML check is used.
  * limit (default 50) and offset: pagination.

  Behavior:

  * Works for user (KYC) and business (KYB) session IDs.
  * Returns { count, next, previous, results }, newest first by completed\_at. count is exact up to 100 and capped at 100 above that, so follow next until it is null.
  * Only ongoing-monitoring re-screens are listed. The first screening is part of the session decision, so a session without ongoing monitoring returns an empty list.
  * History starts when the feature was introduced; earlier screenings are not reconstructed.

  Example call:
  curl -X GET "[https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/aml-screening-history/](https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/aml-screening-history/)" \
  -H "x-api-key: YOUR\_API\_KEY"

  What to read from the response:

  * results\[].completed\_at: when the re-screen finished. started\_at: when its batch started.
  * results\[].outcome: NO\_CHANGE (completed, result unchanged), CHANGED (score, status or hits moved) or FAILED (no usable answer for this subject, nothing changed).
  * results\[].status, score and total\_hits: the state the re-screen left the check in.
  * results\[].dataset\_freshness: how current the screening datasets were (sources.sanctions, pep, warnings, adverse\_media with last\_updated\_at and oldest\_updated\_at), or null when no dates were available. Dates are never estimated.
  * results\[].provider and dataset\_freshness.provider: an identifier of the data source. Treat it as an opaque string.

  Failure modes:

  * 400: limit or offset above 1,000,000.
  * 401: the API key has expired.
  * 403: missing or invalid key, a key of another application, a scoped key without decisions: read, or a request from outside the key's IP allowlist.
  * 404: the session does not exist, was deleted, or is outside a scoped key's limits, or it has no AML check (for that node\_id).

  Side effects: none. This is a pure read.

  For the full integration shape, see /integration/integration-prompt.\`
Paste into Alerts, activity entries and webhooks fire only when a screening result moves, so this history is the record that a clean subject was still being screened. [Continuous AML monitoring](/core-technology/aml-screening/continuous-monitoring-aml-screening.md) explains how re-screens run and what each field means. To hand the same history to an auditor as a file, use [Export AML screening history](/management-api/sessions/export-aml-screening-history.md). ## OpenAPI ````yaml GET /v3/session/{sessionId}/aml-screening-history/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: Identity verification API. Authenticate with x-api-key header. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/{sessionId}/aml-screening-history/: get: tags: - Sessions summary: List AML screening history description: >- List every completed ongoing-monitoring re-screen of a session's AML check, newest first by `completed_at`, including the runs where nothing changed: alerts, activity entries and webhooks fire only when a result moves, so this history is the evidence that a clean subject was still being screened. Works for KYC and KYB session IDs; pass `node_id` when the session ran more than one AML step. Only ongoing-monitoring re-screens are listed (the first screening is part of the session decision) and runs from before this history existed are not reconstructed, so a session without ongoing monitoring returns an empty list. `count` is exact up to 100 and capped at 100 above that, so follow `next` until it is `null`. A scoped API key needs `decisions: read`; see [Continuous AML monitoring](https://docs.didit.me/core-technology/aml-screening/continuous-monitoring-aml-screening). operationId: get_v3_session_aml_screening_history parameters: - name: sessionId in: path required: true description: >- UUID of the verification session (the `session_id` returned by `POST /v3/session/`). Accepts both User Verification (KYC) and Business Verification (KYB) session IDs: the server resolves the ID across both session types. Must be a well-formed UUID; a malformed value does not match the route and returns an HTML `404`. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 - name: node_id in: query required: false description: >- Workflow graph node ID of the AML check. Needed only when the session ran more than one AML step; without it the most recent AML check is used. An unknown node returns `404`. schema: type: string example: feature_aml_1 - name: limit in: query required: false description: >- Maximum number of screening runs per page. Defaults to 50. A value below 1 or a non-numeric value falls back to 50; a value above 1,000,000 returns `400`. schema: type: integer default: 50 minimum: 1 maximum: 1000000 example: 50 - name: offset in: query required: false description: >- Number of results to skip before the first returned one. Defaults to 0; a negative or non-numeric value falls back to 0, a value above 1,000,000 returns `400`. Prefer following the `next` and `previous` URLs. schema: type: integer default: 0 minimum: 0 maximum: 1000000 example: 0 - name: ordering in: query required: false description: >- Optional sort override. The default order is `-completed_at`. Pass a result field name (for example `completed_at`, `started_at`, `outcome` or `score`) to sort ascending, prefix it with `-` to sort descending, and separate several fields with commas. Unknown fields are ignored. schema: type: string example: completed_at responses: '200': description: One page of screening runs, newest first. content: application/json: schema: type: object required: - count - next - previous - results properties: count: type: integer maximum: 100 description: >- Number of runs, exact up to 100 and capped at 100 above that. next: type: string format: uri nullable: true description: URL of the next page, or `null` on the last page. previous: type: string format: uri nullable: true description: URL of the previous page, or `null` on the first page. results: type: array items: $ref: '#/components/schemas/AMLScreeningRun' examples: Monitored subject: value: count: 2 next: null previous: null results: - uuid: dddddddd-1111-2222-3333-444444444444 completed_at: '2026-09-14T04:12:33.481207Z' started_at: '2026-09-14T04:00:01.002311Z' outcome: NO_CHANGE trigger: ONGOING_MONITORING provider: aml_data_source status: Approved score: 0 total_hits: 0 dataset_freshness: captured_at: '2026-09-14T03:58:02.114820+00:00' provider: aml_data_source catalog_version: '2026-09-13' sources: sanctions: last_updated_at: '2026-09-13T21:10:00+00:00' oldest_updated_at: '2026-09-11T06:00:00+00:00' dataset_count: 120 dated_dataset_count: 120 pep: last_updated_at: '2026-09-13T08:00:00+00:00' oldest_updated_at: null dataset_count: 45 dated_dataset_count: 44 warnings: last_updated_at: '2026-09-12T18:45:00+00:00' oldest_updated_at: '2026-09-01T00:00:00+00:00' dataset_count: 30 dated_dataset_count: 30 - uuid: eeeeeeee-1111-2222-3333-444444444444 completed_at: '2026-09-13T04:11:58.020914Z' started_at: '2026-09-13T04:00:00.871022Z' outcome: FAILED trigger: ONGOING_MONITORING provider: aml_data_source status: Approved score: 0 total_hits: 0 dataset_freshness: null '400': description: >- `limit` or `offset` is above 1,000,000. The body is a JSON array with one message. content: application/json: examples: Limit too large: summary: limit=2000000 value: - limit must not exceed 1000000. Offset too large: summary: offset=2000000 value: - offset must not exceed 1000000. schema: type: array items: type: string '401': description: >- The scoped API key has expired. This is the only case that returns `401`: a missing, invalid or revoked key returns `403`. content: application/json: schema: type: object properties: detail: type: string description: Human-readable error message. examples: Expired key: summary: The key's expiry date has passed value: detail: This API key has expired. '403': description: >- Authentication or authorization failure. Missing, invalid and revoked keys return `403` (not `401`); so do a key of another application, a scoped key without the permission this endpoint needs, and a request from outside the key's IP allowlist. Distinguish them by `detail`. content: application/json: schema: type: object properties: detail: type: string description: Human-readable error message. examples: Missing or invalid credentials: summary: No x-api-key header, or the key failed validation value: detail: >- Authentication credentials were not provided or are invalid. Other application: summary: >- A valid key that belongs to a different application than the session value: detail: You do not have permission to perform this action. Scoped key without decisions read: summary: 'Scoped key lacks decisions: read' value: detail: This API key has no read access to decisions. IP not allowed: summary: Request from outside the key's IP allowlist value: detail: This API key can't be used from this IP address. '404': description: >- The session does not exist, was deleted or is outside a scoped key's limits, or it has no AML check (for the given `node_id`). The session lookup runs before the credential check, so an unknown `sessionId` returns `404` even without a valid key. content: application/json: schema: type: object properties: detail: type: string description: Human-readable error message. examples: Unknown session: summary: No session with this ID exists, or it was deleted value: detail: Not found. Outside key limits: summary: >- The session is outside a scoped key's limits (also returned for a session deleted moments ago) value: detail: Session not found. No AML check: summary: The session never ran an AML step value: detail: The session does not have an AML check. No AML check for node: summary: node_id does not match an AML check of the session value: detail: >- The session does not have an AML check for node 'feature_aml_2'. '429': description: >- Rate limit exceeded: 600 GET requests per minute per API key. Wait `Retry-After` seconds before retrying; the `X-RateLimit-*` headers show the budget. content: application/json: schema: type: object properties: detail: type: string description: Human-readable error message. examples: Rate limited: summary: Budget for the current minute exhausted value: detail: >- GET request rate limit exceeded. You can make up to 600 requests per minute. headers: Retry-After: description: Seconds to wait before retrying. schema: type: integer minimum: 1 example: 30 security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: >- curl -X GET 'https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/aml-screening-history/' \ -H 'x-api-key: YOUR_API_KEY' - lang: python label: Python source: |- import os import requests session_id = '11111111-2222-3333-4444-555555555555' resp = requests.get( f'https://verification.didit.me/v3/session/{session_id}/aml-screening-history/', headers={'x-api-key': os.environ['DIDIT_API_KEY']}, timeout=10, ) resp.raise_for_status() for run in resp.json()['results']: print(run['completed_at'], run['outcome'], run['status']) - lang: javascript label: JavaScript source: >- const sessionId = '11111111-2222-3333-4444-555555555555'; const resp = await fetch(`https://verification.didit.me/v3/session/${sessionId}/aml-screening-history/`, { headers: { 'x-api-key': process.env.DIDIT_API_KEY }, }); if (!resp.ok) throw new Error(`Request failed: ${resp.status}`); const page = await resp.json(); for (const run of page.results) console.log(run.completed_at, run.outcome, run.status); components: schemas: AMLScreeningRun: type: object description: One completed ongoing-monitoring re-screen of an AML check. required: - uuid - completed_at - started_at - outcome - trigger - provider - status - score - total_hits - dataset_freshness properties: uuid: type: string format: uuid description: Identifier of this screening run. completed_at: type: string format: date-time description: >- When this subject's re-screen finished. Results are ordered by it, newest first. started_at: type: string format: date-time description: When the monitoring batch this re-screen belongs to started. outcome: type: string enum: - NO_CHANGE - CHANGED - FAILED description: >- `NO_CHANGE`: completed and the result did not move. `CHANGED`: completed and the score, status, hit count or hits changed. `FAILED`: no usable answer for this subject, so the check was left as it was. trigger: type: string enum: - ONGOING_MONITORING description: What started the screening. Always `ONGOING_MONITORING` today. provider: type: string description: >- Opaque identifier of the AML data source that answered. Treat it as an opaque string; do not branch on it. example: aml_data_source status: type: string nullable: true enum: - Not Finished - Approved - Declined - In Review - Resub Requested - null description: AML check status this run left the check in. score: type: number format: float nullable: true minimum: 0 maximum: 100 description: AML score this run left the check in. total_hits: type: integer nullable: true description: Number of hits this run left the check in. dataset_freshness: allOf: - $ref: '#/components/schemas/AMLDatasetFreshness' nullable: true description: >- Dataset freshness behind this run, or `null` when no dates were available. AMLDatasetFreshness: type: object description: >- How current the AML datasets were when a screening ran. Dates are never estimated. required: - captured_at - provider - catalog_version - sources properties: captured_at: type: string format: date-time description: When Didit read the dataset catalog this freshness comes from. provider: type: string description: >- Opaque identifier of the AML data source. Treat it as an opaque string; do not branch on it. example: aml_data_source catalog_version: type: string nullable: true description: >- Version identifier of the dataset catalog, when the source reports one. sources: type: object description: >- Freshness per dataset family. A family whose datasets reported no update date is absent rather than filled with `null`. properties: sanctions: $ref: '#/components/schemas/AMLDatasetSourceFreshness' pep: $ref: '#/components/schemas/AMLDatasetSourceFreshness' warnings: $ref: '#/components/schemas/AMLDatasetSourceFreshness' adverse_media: $ref: '#/components/schemas/AMLDatasetSourceFreshness' AMLDatasetSourceFreshness: type: object description: Freshness of one family of AML datasets. required: - last_updated_at - oldest_updated_at - dataset_count - dated_dataset_count properties: last_updated_at: type: string format: date-time description: Most recent update of any dataset in the family. oldest_updated_at: type: string format: date-time nullable: true description: >- Staleness bound: every dataset in the family is at least this current. `null` when at least one dataset in the family reported no update date, because the bound is then unknown. dataset_count: type: integer description: Number of datasets in the family. dated_dataset_count: type: integer description: Number of those datasets that reported an update date. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Your application's API key, from Developers -> API keys in the Business Console. The primary key has full access. A named key can be scoped: none, read or write per resource, limited to some workflows or to approved sessions, to a list of IP addresses, and to an expiry date. 401 means the key is missing, wrong, revoked or expired; 403 means the key has no access to this resource or action, or the request came from an address outside its IP list; 404 on a session route means the session is outside the key's workflows or statuses. A key without media access receives image, video and PDF URLs as null, and a key without sessions write receives session links and tokens as null. See https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.