> ## 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. # API de mise à jour du statut AML > Définissez le statut du filtrage AML d'une session (ex. approuvé après levée des correspondances) sans modifier la décision globale de Didit. Prompt de l'API de mise à jour du statut de contrôle AML Copier le prompt dans le presse-papiers \

\`Set the status of the AML screening check of a Didit verification session through the API.

Endpoint:
PATCH https://verification.didit.me/v3/session/{session_id}/update-aml-status/

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

Goal:
\- Record my compliance decision on a session's AML check as a whole (the status of an aml_screenings[] entry in the session decision), for example Approved after my team cleared every hit.

Request body (JSON):
\- status (required): "Approved", "Declined", "In Review", "Not Finished" or "Resub Requested".
\- node_id (optional): the workflow node ID of the AML check when the session ran several AML steps. It can also be sent as the node_id query parameter. Without it the most recent AML check is updated.

Behavior:
\- Works for user (KYC) and business (KYB) session IDs.
\- Only the AML check changes. The session status is not recomputed: use PATCH /v3/session/{session_id}/update-status/ to change the session decision, and PATCH /v3/session/{session_id}/update-aml-hit-status/ to mark individual hits.
\- When the status changes, Didit adds an AML_STATUS_UPDATED activity entry and sends a data.updated webhook.
\- Sending the status the check already has returns 200 and changes nothing (no activity entry, no webhook).

Example call:
curl -X PATCH "https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/update-aml-status/" \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"status": "Approved"}'

What to read from the response:
\- status: the AML check status now.
\- previous_status: the status before the call (equal to status when nothing changed).

Failure modes:
\- 400: status missing or not one of the allowed values.
\- 401: the API key has expired.
\- 403: missing key (a wrong, revoked or expired key gets 401), a key of another application, a scoped key without decisions: write, 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). This is checked before the body, so it wins over a 400.

Side effects: changes the AML check status, adds an activity entry and sends a data.updated webhook (only when the status changed).

For the full integration shape, see /integration/integration-prompt.`

\
Coller dans Pour décider au cas par cas des correspondances plutôt que pour l'ensemble du contrôle, utilisez [Mettre à jour le statut d'une correspondance AML](https://docs.didit.me/fr/sessions-api/update-aml-hit-status.md). Pour savoir comment les résultats de filtrage et leurs statuts sont produits, consultez [Filtrage AML](https://docs.didit.me/fr/core-technology/aml-screening/overview.md). ## OpenAPI ````yaml fr/openapi-25.json PATCH /v3/session/{sessionId}/update-aml-status/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de vérification d'identité. Authentifiez-vous avec l'en-tête x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/{sessionId}/update-aml-status/: patch: tags: - Sessions summary: Mettre à jour le statut d'une vérification AML description: >- Définissez le statut du contrôle de filtrage AML d'une session dans son ensemble (le `status` d'une entrée `aml_screenings[]` dans la décision de la session), par exemple `Approved` après que votre équipe a écarté chaque résultat. Fonctionne pour les identifiants de session KYC et KYB ; transmettez `node_id` (paramètre de requête ou champ du corps) lorsque la session a exécuté plusieurs étapes AML, sinon le contrôle AML le plus récent est mis à jour. Lorsque le statut change effectivement, une entrée d'activité `AML_STATUS_UPDATED` est enregistrée et un [webhook](https://docs.didit.me/fr/integration/webhooks) `data.updated` est envoyé ; envoyer le statut actuel renvoie `200` et ne modifie rien. Le statut de la session n'est pas recalculé : utilisez `PATCH /v3/session/{sessionId}/update-status/` pour la décision de la session et `PATCH /v3/session/{sessionId}/update-aml-hit-status/` pour les résultats individuels. Une clé API avec périmètre restreint nécessite `decisions: write`. operationId: patch_v3_session_update_aml_status parameters: - name: sessionId in: path required: true description: >- UUID de la session de vérification (le `session_id` renvoyé par `POST /v3/session/`). Accepte les identifiants de session de Vérification des utilisateurs (KYC) et de Vérification d'entreprise (KYB) : le serveur résout l'identifiant pour les deux types de session. Doit être un UUID bien formé ; une valeur malformée ne correspond pas à la route et renvoie une erreur HTML `404`. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 - name: node_id in: query required: false description: >- ID de nœud du graphe de workflow du contrôle AML à mettre à jour. Nécessaire uniquement lorsque la session a exécuté plusieurs étapes AML. Prévaudra sur `node_id` dans le corps. schema: type: string example: feature_aml_1 requestBody: required: true content: application/json: schema: type: object required: - status properties: status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: Nouveau statut de la vérification AML. example: Approved node_id: type: string description: >- ID de nœud du graphe de workflow du contrôle AML, comme alternative au paramètre de requête. example: feature_aml_1 example: status: Approved responses: '200': description: >- Statut de vérification AML défini (ou inchangé lorsqu'il avait déjà cette valeur). content: application/json: schema: type: object required: - message - status - previous_status properties: message: type: string description: Toujours `AML status updated successfully`. status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: Statut du contrôle AML actuel. previous_status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: >- Statut avant l'appel. Égal à `status` lorsque rien n'a changé. example: message: AML status updated successfully status: Approved previous_status: In Review '400': description: >- Erreur de validation : `status` manquant ou ne faisant pas partie des valeurs autorisées. La recherche de vérification AML s'exécute en premier, donc une session sans vérification AML renvoie `404` même avec un corps invalide. content: application/json: examples: Missing status: summary: Corps vide ou aucun statut value: status: - This field is required. Invalid status: summary: status n'est pas dans l'enum value: status: - '"Cleared" is not a valid choice.' '401': description: >- La clé API restreinte a expiré. C'est le seul cas qui renvoie `401` : une clé manquante, invalide ou révoquée renvoie `403`. content: application/json: schema: type: object properties: detail: type: string description: Message d'erreur lisible par l'humain. examples: Expired key: summary: La date d'expiration de la clé est dépassée value: detail: This API key has expired. '403': description: >- Échec d'authentification ou d'autorisation. Une clé manquante renvoie `403`, tout comme la clé d'une autre application, une clé restreinte ne disposant pas de l'autorisation requise par cet endpoint, ou une requête provenant de l'extérieur de la liste d'adresses IP autorisées de la clé ; une clé incorrecte, révoquée ou expirée renvoie `401`. Distinguez-les grâce au champ `detail`. content: application/json: schema: type: object properties: detail: type: string description: Message d'erreur lisible par l'humain. examples: Missing or invalid credentials: summary: Aucun en-tête x-api-key, ou la validation de la clé a échoué value: detail: >- Authentication credentials were not provided or are invalid. Other application: summary: >- Une clé valide qui appartient à une application différente de la session value: detail: You do not have permission to perform this action. Scoped key without decisions write: summary: 'La clé restreinte ne dispose pas de decisions: write' value: detail: This API key has no write access to decisions. IP not allowed: summary: >- Requête provenant de l'extérieur de la liste d'adresses IP autorisées de la clé value: detail: This API key can't be used from this IP address. '404': description: >- La session n'existe pas, a été supprimée ou se trouve en dehors des limites d'une clé restreinte, ou elle ne comporte aucune vérification AML (pour le `node_id` indiqué). La recherche de session s'exécute avant la vérification des identifiants, donc un `sessionId` inconnu renvoie `404` même sans clé valide. content: application/json: schema: type: object properties: detail: type: string description: Message d'erreur lisible par l'humain. examples: Unknown session: summary: Aucune session avec cet ID n'existe, ou elle a été supprimée value: detail: Not found. Outside key limits: summary: >- La session se trouve en dehors des limites d'une clé restreinte (également renvoyée pour une session supprimée il y a quelques instants) value: detail: Session not found. No AML check: summary: La session n'a jamais exécuté d'étape AML value: detail: The session does not have an AML check. No AML check for node: summary: >- node_id ne correspond à aucune vérification AML de la session value: detail: >- The session does not have an AML check for node 'feature_aml_2'. '429': description: >- Limite de débit dépassée : 300 requêtes d'écriture (POST, PATCH, DELETE) par minute par clé API. Attendez `Retry-After` secondes avant de réessayer ; les en-têtes `X-RateLimit-*` indiquent le budget. content: application/json: schema: type: object properties: detail: type: string description: Message d'erreur lisible par l'humain. examples: Rate limited: summary: Budget épuisé pour la minute en cours value: detail: >- Write request rate limit exceeded. You can make up to 300 requests per minute. headers: Retry-After: description: Secondes à attendre avant de réessayer. schema: type: integer minimum: 1 example: 30 security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: >- curl -X PATCH 'https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/update-aml-status/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"status": "Approved"}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.sessions.update_aml_status( "11111111-2222-3333-4444-555555555555", status="Approved", ) print(result) - lang: javascript label: Node.js source: >- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.sessions.updateAmlStatus("11111111-2222-3333-4444-555555555555", { status: "Approved", }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.UpdateAMLStatus(ctx, \"11111111-2222-3333-4444-555555555555\", didit.SessionsUpdateAMLStatusParams{\n\tStatus: \"Approved\",\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.SessionsUpdateAmlStatusParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.sessions().updateAmlStatus("11111111-2222-3333-4444-555555555555", SessionsUpdateAmlStatusParams.builder() .status(SessionsUpdateAmlStatusParams.Status.of("Approved")) .build()); System.out.println(result); - lang: php label: PHP source: >- sessions->updateAmlStatus('11111111-2222-3333-4444-555555555555', [ 'status' => 'Approved', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.sessions.update_aml_status( "11111111-2222-3333-4444-555555555555", status: "Approved" ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Sessions.UpdateAmlStatusAsync("11111111-2222-3333-4444-555555555555", new SessionsUpdateAmlStatusParams { Status = "Approved", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- 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. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.