> ## 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. # Mise à jour du statut : approuver ou refuser une étape > Approuvez, refusez ou repassez en revue une étape (OCR, vivacité, correspondance faciale, AML, justificatif de domicile, téléphone) avec Didit. Prompt de mise à jour du statut de fonctionnalité Copier le prompt dans le presse-papiers \

\`Approve, decline, or move a SINGLE verification step (feature) of a Didit session to review, now or once the person finishes the flow.

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

Authentication:
x-api-key (client API key) or a user-auth token. Privilege: write:sessions.

Path parameters:
\- session_id (UUID) — KYC or KYB; Didit resolves it against both session types.
\- node_id — the workflow graph node ID of the step (e.g. feature_ocr_1, feature_liveness_1, feature_aml_1). Use the literal "default" for non-graph (single-step) workflows where the step has no node ID.

Request body:
\- new_status (string, required): one of "Approved", "Declined", "In Review". Must differ from the step's current status.
\- comment (string, optional): your reason, saved in the session's activity and returned as the override's reason.
\- feature_type (string, optional): which kind of step to target, for example "LIVENESS", "AML", "FACE_MATCH", "ID_VERIFICATION". Needed when node_id is "default" (non-graph workflows, where steps have no node ID). An unknown value returns 400 { "feature_type": ["Unknown feature_type '...'."] }.
\- defer_until_flow_finishes (boolean, optional, default false): while the person is still in the flow, wait and apply the override when the flow finishes instead of at once.

When the override applies:
\- Omitted or false: it applies at once. If the person is still in the flow it is recorded as forced=true.
\- true while the person is still in the flow (session Not Started, In Progress or Resubmitted, and not finished): it is stored as "pending_until_flow_finishes" and applies when the flow finishes, after the flow reaches its own decision.
\- true after the flow ended: it applies at once.
\- A waiting override is cancelled instead when the person redoes the step before finishing, a newer override on the same step replaces it, the session leaves the flow unfinished (abandoned, expired, decided mid-flow), or you cancel it with POST /v3/session/{session_id}/features/overrides/{override_id}/cancel/.

Which steps this works on:
Every per-step feature record: OCR/ID, Liveness, Face Match, NFC, AML, Proof of Address (POA), Phone, Email, Database Validation, Questionnaire, and the KYB registry / documents / key-people checks.

Difference vs update-status:
\- update-status changes the OVERALL session decision (Approved/Declined/Resubmitted).
\- THIS endpoint changes ONE step's status. A session that already has a decision keeps it. If the session has no decision yet and its workflow is waiting on exactly this step, applying the override completes the step: the workflow moves on and a status node can set the session decision (and fire status.updated).

Not allowed:
\- Standalone API sessions (session_type = API) return 400.

curl example — approve the ID/OCR step:
curl -X PATCH https://verification.didit.me/v3/session//features/feature_ocr_1/update-status/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{ "new_status": "Approved", "comment": "Document manually verified" }'

Response: { session_id, node_id, feature_type, new_status, override }.
\- node_id is the step's workflow node, or null for a step without a node ("default" in a non-graph workflow).
\- new_status is the step's stored status: the requested one once the override applied, the unchanged one while it waits.
\- override: { id, node_id, feature_type, feature_model, previous_status, new_status, state ("applied" | "pending_until_flow_finishes" | "cancelled"), forced, reason, requested_by { email, name, type }, requested_at, applied_at, cancelled_at, cancel_reason }.

Side effects:
\- Fires a data.updated webhook when the override applies (at once, or when the flow finishes). Nothing is sent while it waits or when it is cancelled.
\- Records the override in the session's activity as FEATURE_OVERRIDE_PENDING, FEATURE_OVERRIDE_APPLIED or FEATURE_OVERRIDE_CANCELLED, with who made it; the request's entry carries your comment. In the decision's reviews array these entries appear with new_status null, and the request's entry has your reason in comment.

Failure modes:
\- 400: new_status invalid or unchanged, unknown feature_type, or the session is a standalone API session.
\- 401: the scoped API key has expired.
\- 403: missing credentials (a wrong, revoked or expired key gets 401), or the caller lacks write:sessions (a scoped key needs decisions write).
\- 404: session not found, or no feature has the given node_id.

Related: list overrides with GET /v3/session/{session_id}/features/overrides/ (see /sessions-api/list-feature-overrides); cancel a waiting one with POST /v3/session/{session_id}/features/overrides/{override_id}/cancel/ (see /sessions-api/cancel-feature-override).

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\
Coller dans ## Ce que fait cet endpointUne session de vérification se compose de **fonctionnalités** (étapes) individuelles : ID/OCR, Liveness, Face Match, AML, justificatif de domicile, téléphone, etc. Cet endpoint vous permet de définir le statut de **l'une** de ces étapes sur `Approved`, `Declined` ou `In Review`.Utilisez [update-status](https://docs.didit.me/fr/sessions-api/update-status.md) lorsque vous voulez approuver, refuser ou rouvrir la session entière. Utilisez **cet** endpoint lorsque vous voulez seulement enregistrer une décision sur une étape unique, par exemple pour marquer l'étape Face Match comme `Declined` dans le cadre de votre propre processus de revue.Une session qui a déjà une décision la conserve : seule l'étape change. Si la session n'a pas encore de décision et que son workflow attend précisément cette étape, l'application de la dérogation termine l'étape, comme si elle était terminée normalement. Le workflow poursuit alors son cours, les étapes suivantes s'exécutent, et un nœud de statut peut définir la décision de la session et déclencher un webhook `status.updated`.## Cibler une étape avec `node_id`Dans les workflows basés sur un graphe, chaque étape possède un `node_id` (par exemple `feature_ocr_1`, `feature_liveness_1`, `feature_aml_1`). Vous les trouvez dans la [décision de session](https://docs.didit.me/fr/sessions-api/retrieve-session.md) : chaque fonctionnalité d'une décision V3 porte son `node_id`.Pour les workflows **sans graphe (à étape unique)**, la fonctionnalité sous-jacente n'a pas d'identifiant de nœud. Transmettez la valeur littérale `default` comme `nodeId` pour la cibler. Comme aucune étape de ce type de workflow n'a d'identifiant de nœud, transmettez aussi `feature_type` (par exemple `LIVENESS`, `AML` ou `FACE_MATCH`) pour indiquer l'étape visée. Un `feature_type` inconnu renvoie `400`.## Attendre que la personne termine le parcoursPar défaut, la dérogation s'applique immédiatement. Si la personne est toujours en train de parcourir le parcours, cela modifie une étape d'un parcours encore en cours ; la dérogation est alors enregistrée avec `forced: true`.Définissez `defer_until_flow_finishes: true` pour attendre à la place. Tant que la session est `Not Started`, `In Progress` ou `Resubmitted` et que la personne n'a pas terminé, la dérogation est stockée comme `pending_until_flow_finishes`. Elle s'applique lorsque la personne termine le parcours, après que le parcours a atteint sa propre décision. Sur une session dont le parcours est déjà terminé, elle s'applique immédiatement dans tous les cas.Une dérogation en attente est annulée au lieu d'être appliquée lorsque :- la personne refait l'étape avant de terminer (`check_changed`), - une dérogation plus récente sur la même étape la remplace (`replaced`), - la session quitte le parcours sans l'avoir terminé : abandonnée, expirée ou décidée en cours de parcours (`session_closed`), - vous l'annulez avec [Annuler une dérogation de fonctionnalité](https://docs.didit.me/fr/sessions-api/cancel-feature-override.md) (`cancelled_by_reviewer`).Le champ `override` de la réponse indique ce qui s'est passé : `state` vaut `applied` ou `pending_until_flow_finishes`, et `applied_at` est renseigné une fois la dérogation appliquée. Le `new_status` de premier niveau correspond au statut stocké de l'étape, il reste donc inchangé pendant que la dérogation attend. Utilisez [Lister les dérogations de fonctionnalités](https://docs.didit.me/fr/sessions-api/list-feature-overrides.md) pour voir toutes les dérogations d'une session et savoir si la personne est encore dans le parcours.## Prise en charge KYC et KYBFonctionne de la même manière pour les sessions **Vérification des utilisateurs (KYC)** et **Vérification d'entreprise (KYB)** : Didit résout le `sessionId` pour les deux. Les types d'étapes pris en charge sont ID/OCR, Liveness, Face Match, NFC, AML, justificatif de domicile, téléphone, e-mail, validation en base de données, **Questionnaires**, ainsi que les contrôles du registre KYB, des documents et des personnes clés.> [!NOTE] > > Les statuts des fonctionnalités individuelles des sessions API autonomes (celles créées via les API de vérification autonomes, `session_type = API`) ne peuvent pas être modifiés : l'endpoint renvoie `400`.## Exemples> [tab] Approuver une étape > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/feature_ocr_1/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "Approved", > "comment": "Document manually verified by compliance" > }' > ```> [tab] Refuser l'étape Face Match > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/feature_face_match/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "Declined" > }' > ```> [tab] Workflow à étape unique (nœud par défaut) > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/default/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "In Review", > "feature_type": "LIVENESS" > }' > ```> [tab] Attendre que la personne termine le parcours > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/feature_liveness_1/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "Approved", > "comment": "Liveness retried with a reviewer present", > "defer_until_flow_finishes": true > }' > ```## Ce qui se passe après une mise à jour- **Webhook** : un événement `data.updated` est envoyé lorsque la dérogation s'applique, immédiatement ou à la fin du parcours. Rien n'est envoyé pendant qu'elle attend ni lorsqu'elle est annulée. - **Activité** : chaque dérogation est enregistrée dans l'activité de la session sous `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` ou `FEATURE_OVERRIDE_CANCELLED`, avec l'auteur (clé API, utilisateur, ou le système lorsqu'une dérogation en attente s'applique). L'entrée de la requête porte votre `comment` comme motif. Dans le tableau `reviews` de la [décision de session](https://docs.didit.me/fr/sessions-api/retrieve-session.md), ces entrées apparaissent avec `new_status: null`, et l'entrée de la requête porte votre motif dans `comment`. - **Décision de session** : une session qui a déjà une décision la conserve. Pour modifier la décision finale, appelez séparément [update-status](https://docs.didit.me/fr/sessions-api/update-status.md).## AutorisationNécessite le privilège `write:sessions`, avec soit une clé API client (`x-api-key`), soit un en-tête d'autorisation utilisateur. Une clé API limitée à des périmètres doit disposer d'un accès en écriture aux décisions.## Voir aussi- [Mettre à jour le statut de session](https://docs.didit.me/fr/sessions-api/update-status.md) : modifier la décision globale de la session. - [Mettre à jour le statut d'une correspondance AML](https://docs.didit.me/fr/sessions-api/update-aml-hit-status.md) : examiner les correspondances AML individuelles. - [Récupérer une session](https://docs.didit.me/fr/sessions-api/retrieve-session.md) : obtenir la décision (et le `node_id` de chaque fonctionnalité). - [Webhooks](https://docs.didit.me/fr/integration/webhooks.md) : s'abonner à `data.updated`. - [Lister les dérogations de fonctionnalités](https://docs.didit.me/fr/sessions-api/list-feature-overrides.md) : chaque dérogation d'une session et son état. - [Annuler une dérogation de fonctionnalité](https://docs.didit.me/fr/sessions-api/cancel-feature-override.md) : empêcher une dérogation en attente de s'appliquer. ## OpenAPI ````yaml fr/openapi-25.json PATCH /v3/session/{sessionId}/features/{nodeId}/update-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}/features/{nodeId}/update-status/: patch: tags: - Sessions summary: Mettre à jour le statut d'une fonctionnalité (étape) individuelle description: >- Définissez le statut d'une fonctionnalité (étape) de vérification individuelle au sein d'une session. Ciblez la fonctionnalité par son `nodeId` dans le graphe du workflow. Sur les workflows sans graphe, dont les étapes n'ont pas de nœud, utilisez `default` et transmettez également `feature_type` pour indiquer l'étape concernée. Fonctionne aussi bien pour les sessions de Vérification des utilisateurs (KYC) que pour celles de Vérification d'entreprise (KYB) et pour chaque type d'étape : ID/OCR, Détection du vivant, Correspondance faciale, NFC, AML, Justificatif de domicile, Téléphone, E-mail, Validation en base de données, Questionnaire, ainsi que les vérifications KYB de registre / documents / personnes clés. Cet endpoint n'est **pas** disponible pour les sessions API autonomes (`session_type = API`). `new_status` doit être l'un des suivants : `Approved`, `Declined` ou `In Review`, et doit différer du statut actuel de la fonctionnalité. **Quand la dérogation s'applique.** Sans `defer_until_flow_finishes` (ou avec `false`), la dérogation s'applique immédiatement, comme c'était déjà le cas ; lorsque la personne se trouve encore dans le flux, elle est enregistrée en tant que `forced`. Avec `defer_until_flow_finishes: true` pendant que la personne se trouve encore dans le flux (la session est `Not Started`, `In Progress` ou `Resubmitted` et n'est pas terminée), la dérogation est stockée en tant que `pending_until_flow_finishes` et s'applique à la fin du flux, après que le flux a atteint sa propre décision. Sur une session dont le flux s'est déjà terminé, elle s'applique immédiatement dans les deux cas. Une dérogation en attente est en revanche annulée lorsque la personne recommence son étape avant de terminer, lorsqu'une dérogation plus récente sur la même vérification la remplace, lorsque la session quitte le flux sans l'avoir terminé (abandonnée, expirée ou décidée en cours de flux), ou lorsque vous l'annulez avec `POST /v3/session/{sessionId}/features/overrides/{overrideId}/cancel/`. Listez les dérogations d'une session avec `GET /v3/session/{sessionId}/features/overrides/`. **Effet sur la session.** Une session qui a déjà une décision la conserve : seule la vérification change. Lorsque la session n'a pas encore de décision et que son workflow est précisément en attente de cette étape, l'application de la dérogation valide l'étape : le workflow se poursuit, les étapes ultérieures s'exécutent et un nœud de statut peut définir la décision de la session et déclencher `status.updated`. **Webhooks et activité.** Un webhook `data.updated` se déclenche lorsque la dérogation s'applique (immédiatement ou à la fin du flux), jamais pendant qu'elle est en attente ni lorsqu'elle est annulée. Chaque dérogation est enregistrée dans l'activité de la session sous la mention `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` ou `FEATURE_OVERRIDE_CANCELLED`, avec l'auteur de l'action ; l'entrée de la requête contient votre `comment`. Authentifiez-vous avec votre clé API (`x-api-key`) ou un en-tête d'autorisation utilisateur comportant le privilège `write:sessions` ; une clé API restreinte nécessite un accès en écriture aux décisions. operationId: patch_v3_session_update_feature_status parameters: - in: path name: sessionId required: true description: >- 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. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 - in: path name: nodeId required: true description: >- ID de nœud du graphe de workflow de la fonctionnalité à mettre à jour (par exemple `feature_ocr_1`). Utilisez la valeur littérale `default` pour les workflows sans graphe (à étape unique) où la fonctionnalité n'a pas d'ID de nœud. schema: type: string example: feature_ocr_1 requestBody: required: true content: application/json: schema: type: object required: - new_status properties: new_status: type: string description: >- Statut cible pour cette fonctionnalité. Doit être différent de la valeur actuelle. enum: - Approved - Declined - In Review example: Approved comment: type: string description: >- Note en texte libre optionnelle enregistrée dans la piste d'examen de la session pour cette modification de fonctionnalité. example: Document manually verified by compliance. feature_type: type: string enum: - ID_VERIFICATION - OCR - OCR_BACK - NFC - LIVENESS - FACE - AGE_ESTIMATION - AGE_VERIFICATION - FACE_SEARCH - FACE_MATCH - IP_ANALYSIS - AML - PHONE - PHONE_VERIFICATION - EMAIL - EMAIL_VERIFICATION - POA - PROOF_OF_ADDRESS - DATABASE_VALIDATION - DATA_VALIDATION - QUESTIONNAIRE - DOCUMENT_AI - KYB_REGISTRY - KYB_DOCUMENTS - KYB_KEY_PEOPLE - BANK_VERIFICATION - GEOLOCATION description: >- Quel type d'étape cibler. Requis sur les workflows qui ne sont pas de type graphe (`nodeId` = `default`), où chaque étape ne partage aucun nœud ; facultatif sinon. Une valeur inconnue renvoie `400`. example: LIVENESS defer_until_flow_finishes: type: boolean default: false description: >- Tant que la personne est encore dans le flux, enregistrez la dérogation sous `pending_until_flow_finishes` et appliquez-la lorsque le flux se termine, plutôt qu'immédiatement. Si omis ou défini sur `false`, la dérogation s'applique immédiatement. Sur une session dont le flux est déjà terminé, elle s'applique immédiatement dans les deux cas. example: false examples: Apply Now: summary: Approuver immédiatement l'étape d'identité value: new_status: Approved comment: Document manually verified by compliance. Wait For The Flow: summary: >- Approuver l'étape de détection du vivant une fois que la personne a terminé le parcours value: new_status: Approved comment: Liveness retried with a reviewer present. defer_until_flow_finishes: true Non-graph Workflow: summary: >- Cibler l'étape de détection du vivant d'un workflow sans nœuds (nodeId = default) value: new_status: In Review feature_type: LIVENESS responses: '200': description: "La dérogation a été enregistrée. `new_status` est le statut de la vérification tel qu'enregistré\_: celui demandé une fois la dérogation appliquée, ou celui inchangé pendant qu'elle attend la fin du flux. `override` indique ce qui s'est produit." content: application/json: schema: type: object properties: session_id: type: string format: uuid node_id: type: string nullable: true description: >- Le nœud de workflow de l'étape mise à jour, ou `null` pour une étape sans nœud (le chemin `default` dans un workflow sans graphe). example: feature_ocr_1 feature_type: type: string description: >- Nom du modèle de la fonctionnalité mise à jour (par ex. `KYC`, `Face`, `FaceMatch`, `AML`, `POA`). example: KYC new_status: type: string description: >- Le statut stocké de la vérification : celui demandé une fois la dérogation appliquée, le statut inchangé tant que la dérogation attend la fin du flux. example: Approved override: $ref: '#/components/schemas/FeatureStatusOverride' required: - session_id - node_id - feature_type - new_status - override examples: Applied: summary: La dérogation s'est appliquée immédiatement value: session_id: 3fa85f64-5717-4562-b3fc-2c963f66afa6 node_id: feature_ocr_1 feature_type: KYC new_status: Approved override: id: 7c9e6679-7425-40de-944b-e07fc1f90ae7 node_id: feature_ocr_1 feature_type: '' feature_model: KYC previous_status: In Review new_status: Approved state: applied forced: false reason: Document manually verified by compliance. requested_by: email: reviewer@example.com name: Alex Reviewer type: CONSOLE_USER requested_at: '2026-10-13T09:15:00Z' applied_at: '2026-10-13T09:15:00Z' cancelled_at: null cancel_reason: null Waiting For The Flow: summary: >- defer_until_flow_finishes alors que la personne est toujours dans le flux value: session_id: 3fa85f64-5717-4562-b3fc-2c963f66afa6 node_id: feature_liveness_1 feature_type: Face new_status: Declined override: id: 9b2f4c1e-8d3a-4e5f-a6b7-c8d9e0f1a2b3 node_id: feature_liveness_1 feature_type: '' feature_model: Face previous_status: Declined new_status: Approved state: pending_until_flow_finishes forced: false reason: Liveness retried with a reviewer present. requested_by: email: reviewer@example.com name: Alex Reviewer type: CONSOLE_USER requested_at: '2026-10-13T09:15:00Z' applied_at: null cancelled_at: null cancel_reason: null '400': description: >- Erreur de validation. Renvoyée lorsque `new_status` est invalide ou inchangé, lorsque `feature_type` est inconnu, ou lorsque la session est une session d'API autonome. content: application/json: examples: Same Status: summary: new_status est identique au statut actuel value: new_status: - The new status is the same as the current status. API Session: summary: >- Le statut de la fonctionnalité ne peut pas être modifié sur des sessions d'API autonomes value: - Cannot change feature status for API sessions. Unknown feature_type: summary: feature_type n'est pas un type d'étape connu value: feature_type: - Unknown feature_type 'SELFIE'. '401': description: La clé API restreinte a expiré. content: application/json: examples: Expired API Key: summary: Clé API restreinte ayant dépassé sa date d'expiration value: detail: This API key has expired. '403': description: Identifiants manquants ou autorisations insuffisantes. content: application/json: examples: Invalid Credentials: summary: x-api-key manquant ou invalide value: detail: >- Authentication credentials were not provided or are invalid. Missing Privilege: summary: La clé API ne dispose pas de l'autorisation write:sessions value: detail: You do not have permission to perform this action. Scoped Key Without Access: summary: Clé API restreinte sans accès en écriture aux décisions value: detail: This API key has no write access to decisions. '404': description: >- La session n'a pas été trouvée, ou elle ne possède aucune fonctionnalité avec le `nodeId` indiqué. content: application/json: examples: Session Not Found: summary: session_id inconnu value: detail: Session not found. Feature Not Found: summary: Aucune fonctionnalité pour ce node_id value: detail: >- No feature found with node_id 'feature_ocr_1' in this session. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: |- curl -X PATCH \ https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/features/feature_ocr_1/update-status/ \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "new_status": "Approved", "comment": "Document manually verified by compliance." }' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.sessions.update_feature_status( "11111111-2222-3333-4444-555555555555", "feature_ocr_1", new_status="Approved", comment="Document manually verified by compliance.", ) 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.updateFeatureStatus( "11111111-2222-3333-4444-555555555555", "feature_ocr_1", { new_status: "Approved", comment: "Document manually verified by compliance.", }, ); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.UpdateFeatureStatus(ctx, \"11111111-2222-3333-4444-555555555555\", \"feature_ocr_1\", didit.SessionsUpdateFeatureStatusParams{\n\tNewStatus: \"Approved\",\n\tComment: didit.String(\"Document manually verified by compliance.\"),\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.SessionsUpdateFeatureStatusParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.sessions().updateFeatureStatus("11111111-2222-3333-4444-555555555555", "feature_ocr_1", SessionsUpdateFeatureStatusParams.builder() .newStatus(SessionsUpdateFeatureStatusParams.NewStatus.of("Approved")) .comment("Document manually verified by compliance.") .build()); System.out.println(result); - lang: php label: PHP source: >- sessions->updateFeatureStatus('11111111-2222-3333-4444-555555555555', 'feature_ocr_1', [ 'new_status' => 'Approved', 'comment' => 'Document manually verified by compliance.', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.sessions.update_feature_status( "11111111-2222-3333-4444-555555555555", "feature_ocr_1", new_status: "Approved", comment: "Document manually verified by compliance." ) 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.UpdateFeatureStatusAsync("11111111-2222-3333-4444-555555555555", "feature_ocr_1", new SessionsUpdateFeatureStatusParams { NewStatus = "Approved", Comment = "Document manually verified by compliance.", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: FeatureStatusOverride: type: object description: >- Une modification manuelle (override) du statut d'une vérification (fonctionnalité) effectuée avec `PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/` : ce qu'elle modifie, si elle a été appliquée ou si elle attend toujours que la personne termine le parcours, qui l'a demandée et pourquoi. required: - id - node_id - feature_type - feature_model - previous_status - new_status - state - forced - reason - requested_by - requested_at - applied_at - cancelled_at - cancel_reason properties: id: type: string format: uuid description: >- Identifiant de la dérogation. Transmettez-le à l'endpoint d'annulation. example: 7c9e6679-7425-40de-944b-e07fc1f90ae7 node_id: type: string description: >- Le nœud de workflow spécifié dans la requête (`default` pour une étape sans nœud). example: feature_ocr_1 feature_type: type: string description: >- Le `feature_type` transmis par la requête, ou une chaîne vide si aucun n'a été transmis. example: '' feature_model: type: string description: >- Le type de vérification qui a été remplacé, par exemple `KYC`, `Face`, `AML` ou `GeolocationCheck`. example: KYC previous_status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: >- Le statut de la vérification au moment où la dérogation a été demandée. example: In Review new_status: type: string enum: - Approved - Declined - In Review description: Le statut défini par la dérogation. example: Approved state: type: string enum: - applied - pending_until_flow_finishes - cancelled description: >- `applied` : le contrôle a le nouveau statut. `pending_until_flow_finishes` : la dérogation attend et s'applique lorsque la personne termine le flux. `cancelled` : elle a attendu et ne s'est jamais appliquée (voir `cancel_reason`). example: applied forced: type: boolean description: >- `true` lorsque la dérogation s'est appliquée immédiatement alors que la personne était encore dans le flux. example: false reason: type: string nullable: true description: Le `comment` envoyé avec la requête, ou `null`. example: Document manually verified by compliance. requested_by: type: object nullable: true description: Qui a demandé la dérogation, ou `null` lorsque cela n'est pas connu. properties: email: type: string format: email nullable: true description: >- E-mail de l'utilisateur de la console, ou `null` pour les clés API et le système. example: reviewer@example.com name: type: string nullable: true description: Nom d'affichage du demandeur, ou `null`. example: Alex Reviewer type: type: string enum: - CONSOLE_USER - API_KEY - SYSTEM description: >- Qui a effectué la requête : un utilisateur de la console, une clé API ou Didit lui-même. example: CONSOLE_USER requested_at: type: string format: date-time description: Moment où la dérogation a été demandée. example: '2026-10-13T09:15:00Z' applied_at: type: string format: date-time nullable: true description: >- Date et heure auxquelles la vérification a pris le nouveau statut, ou `null` pendant qu'elle est en attente ou une fois qu'elle est annulée. example: '2026-10-13T09:15:00Z' cancelled_at: type: string format: date-time nullable: true description: Moment où une dérogation en attente a été annulée, ou `null`. example: null cancel_reason: type: string nullable: true enum: - cancelled_by_reviewer - replaced - check_changed - session_closed - null description: >- Raison pour laquelle un remplacement en attente n'a jamais été appliqué, ou `null`. `cancelled_by_reviewer` : annulé avec l'endpoint d'annulation. `replaced` : un remplacement plus récent sur la même vérification l'a remplacé. `check_changed` : la personne a refait la vérification avant de terminer le flux. `session_closed` : la session a quitté le flux avant que la personne ne le termine (abandonnée, expirée ou décidée en cours de flux). example: null 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.