Passer au contenu principal
PATCH
curl

Ce que fait cet endpoint

Une 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 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 : 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 parcours

Par 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é (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 pour voir toutes les dérogations d’une session et savoir si la personne est encore dans le parcours.

Prise en charge KYC et KYB

Fonctionne 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.
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

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, 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.

Autorisation

Né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

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.

Paramètres de chemin

sessionId
string<uuid>
requis

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.

Exemple:

"11111111-2222-3333-4444-555555555555"

nodeId
string
requis

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.

Exemple:

"feature_ocr_1"

Corps

application/json
new_status
enum<string>
requis

Statut cible pour cette fonctionnalité. Doit être différent de la valeur actuelle.

Options disponibles:
Approved,
Declined,
In Review
Exemple:

"Approved"

comment
string

Note en texte libre optionnelle enregistrée dans la piste d'examen de la session pour cette modification de fonctionnalité.

Exemple:

"Document manually verified by compliance."

feature_type
enum<string>

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.

Options disponibles:
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
Exemple:

"LIVENESS"

defer_until_flow_finishes
boolean
défaut:false

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.

Exemple:

false

Réponse

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.

session_id
string<uuid>
requis
node_id
string | null
requis

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).

Exemple:

"feature_ocr_1"

feature_type
string
requis

Nom du modèle de la fonctionnalité mise à jour (par ex. KYC, Face, FaceMatch, AML, POA).

Exemple:

"KYC"

new_status
string
requis

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.

Exemple:

"Approved"

override
object
requis

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.

Dernière modification le 7 novembre 2026