Passer au contenu principal
PATCH
curl

Prise en charge KYC et KYB

Cet endpoint fonctionne de la même manière pour les sessions de Vérification des utilisateurs (KYC) et de Vérification d’entreprise (KYB). Didit résout le session_id pour les deux types de session. La validation des transitions de statut est identique pour les deux, car la même énumération de statuts s’applique aux deux. La réponse ne contient que le session_id. Lisez session_kind depuis Récupérer la session lorsque votre logique en aval doit distinguer le type de session.

Transitions autorisées

Vous pouvez faire passer une session à Approved, Declined ou Resubmitted. Tout autre new_status, y compris In Review, renvoie 400. Le statut actuel de la session doit être l’un des suivants : Approved, Declined, In Review, Kyc Expired, Abandoned ou Resubmitted. Sinon, l’API renvoie 400. Définir Approved ou Declined sur une session qui a déjà ce statut est sans effet : l’API renvoie 200, ne modifie rien, ne déclenche aucun webhook et n’envoie aucun e-mail. Définir Resubmitted sur une session déjà Resubmitted renvoie 400 (The new status is the same as the current status.). Une nouvelle soumission dont nodes_to_resubmit ne contient que des fonctionnalités exclusivement backend (AML, DATABASE_VALIDATION, IP_ANALYSIS) s’exécute automatiquement et renvoie la session à un statut de décision, sans aucune interaction de l’utilisateur. Répéter une telle soumission dans les 30 secondes renvoie 429 Too Many Requests avec un en-tête Retry-After, car une répétition immédiate ne peut pas produire un résultat différent. Ne relancez pas automatiquement une soumission depuis un gestionnaire de webhook chaque fois que vous recevez un statut In Review : examinez d’abord le constat ou modifiez les données sous-jacentes.

Prévisualiser l’e-mail d’abord

Avec send_email: true, Approved et Declined envoient à la personne son e-mail de décision, et Resubmitted lui envoie un nouveau lien accompagné des motifs. Vous pouvez consulter cet e-mail avant de modifier quoi que ce soit :
  1. Appelez Prévisualiser l’e-mail de décision pour Approved ou Declined, ou Prévisualiser l’e-mail de nouvelle soumission pour Resubmitted.
  2. Vérifiez le subject et le html rendus, le recipient, ainsi que will_be_sent / not_sent_reason.
  3. Appelez cet endpoint avec le même new_status (et, pour une nouvelle soumission, les mêmes nodes_to_resubmit), send_email: true, email_address défini sur recipient, la valeur email_language que vous avez prévisualisée, et email_preview_token défini sur preview_token.
Ni l’une ni l’autre des prévisualisations ne modifie la session ni n’envoie quoi que ce soit. La mise à jour envoie alors exactement l’e-mail que vous avez prévisualisé. Le reçu expire au bout de 15 minutes. Si le destinataire, la langue, le statut de la session, l’expéditeur ou l’e-mail ont changé depuis la prévisualisation, la mise à jour renvoie 409 avant toute modification. Relancez la prévisualisation et confirmez avec le nouveau reçu. Envoyer email_preview_token sans send_email: true renvoie 400. L’étape de prévisualisation est facultative : les intégrations existantes peuvent continuer d’appeler ce point de terminaison sans elle.

Exemples

Autorisation

Nécessite le privilège write:sessions. Le même privilège couvre les deux types de session.

Ressources associées

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 à mettre à jour. 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"

Corps

application/json
new_status
enum<string>
requis

Statut cible. Approved et Declined enregistrent une décision manuelle définitive (chacun pouvant également annuler l'autre). Resubmitted efface les étapes sélectionnées et renvoie la session à l'utilisateur. Toute autre valeur renvoie 400.

Options disponibles:
Approved,
Declined,
Resubmitted
Exemple:

"Approved"

comment
string

Motif en texte libre du changement, stocké dans l'historique d'examen de la session et renvoyé dans le tableau reviews de Get Decision. Par exemple Duplicated user.

Exemple:

"All checks passed manual review"

nodes_to_resubmit
object[]

Étapes du workflow que l'utilisateur doit recommencer. Prises en compte uniquement lorsque new_status est Resubmitted. Pour Approved/Declined, les entrées font toujours l'objet d'une validation de schéma (une valeur feature non valide renvoie 400), mais les entrées valides selon le schéma sont sémantiquement ignorées. En cas d'omission, le serveur sélectionne automatiquement les tentatives existantes d'OCR, de détection du vivant, de correspondance faciale, de justificatif de domicile, de téléphone, d'e-mail, d'AML, de validation en base de données et de questionnaire dont le statut est Declined, In Review, Not Finished ou Expired (les tentatives de NFC, d'analyse de l'IP, d'estimation de l'âge, de recherche faciale et de documents KYB ne sont jamais sélectionnées automatiquement ; les tentatives faciales hors correspondance faciale sont sélectionnées en tant que LIVENESS) — les fonctionnalités que l'utilisateur n'a jamais tentées (aucune tentative enregistrée) ne sont PAS sélectionnées, de sorte qu'une session avec zéro tentative renvoie 400 (« No features found that need resubmission ») même si rien n'a été approuvé ; transmettez explicitement nodes_to_resubmit dans ce cas. Les étapes sont exécutées dans l'ordre du graphe du workflow, quel que soit l'ordre dans lequel vous les envoyez. KYB_REGISTRY, KYB_KEY_PEOPLE et l'alias KYB sont rejetés avec un code 400 — ces vérifications parentes sont recalculées à partir de leurs sessions KYC enfants.

send_email
boolean
défaut:false

Indique s'il faut envoyer un e-mail à l'utilisateur concernant le changement. Nécessite email_address. Pour Approved/Declined, l'utilisateur reçoit une notification de statut ; pour Resubmitted, l'e-mail comprend le lien de vérification et les motifs de resoumission par étape.

Exemple:

false

email_address
string<email>

Destinataire de l'e-mail de notification. Requis lorsque send_email est true — l'omettre renvoie 400.

Exemple:

"user@example.com"

email_language
string
défaut:en

Langue de l'e-mail de notification. Accepte n'importe quelle chaîne au niveau du schéma ; les codes non pris en charge basculent silencieusement sur l'anglais (en).

Exemple:

"en"

email_preview_token
string
write-only

Reçu optionnel issu de Preview Decision Email (pour Approved et Declined) ou de Preview Resubmission Email (pour Resubmitted) : son preview_token. Valide uniquement avec send_email: true ; sans cela, la requête renvoie 400. Le destinataire, la langue, le statut de la session, l'expéditeur et l'e-mail (et, pour une nouvelle soumission, les étapes sélectionnées) doivent toujours correspondre à l'aperçu, et le reçu expire après 15 minutes. Dans le cas contraire, la requête renvoie 409 avant que la session ne soit modifiée ou qu'un e-mail ne soit envoyé. Les intégrations existantes peuvent omettre ce champ.

Required string length: 1 - 512

Réponse

Statut mis à jour. La réponse contient uniquement le session_id ; récupérez la session mise à jour via Get Decision. Le webhook status.updated se déclenche dès que la modification est enregistrée. Répéter Approved ou Declined renvoie le même corps et ne modifie rien.

session_id
string<uuid>

UUID de la session mise à jour.

Dernière modification le 7 novembre 2026