Passer au contenu principal
Les sessions sont l’unité de vérification sur Didit. Lorsque vous lancez une vérification, une session est créée ; lorsque la vérification se termine, la session contient le payload complet de la décision. La même API des sessions gère les deux types : Dans la leçon de l’Academy sur ce que voient les utilisateurs, le chapitre à 5:34 compare le parcours hébergé à la création de vos propres écrans, soit précisément l’arbitrage que cette API tranche à votre place.

Le type est déterminé par le workflow

Lorsque vous créez une session, vous transmettez un workflow_id. Le type du workflow détermine si la session est une Vérification des utilisateurs (KYC) ou une Vérification d’entreprise (KYB) : l’appelant ne choisit pas ce type séparément. Les workflows KYB créent des sessions de Vérification d’entreprise (KYB), et les workflows KYC créent des sessions de Vérification des utilisateurs (KYC).

Le discriminant session_kind

Chaque réponse de session (création, lecture, liste, mise à jour du statut, partage et import) contient un champ de premier niveau :
  • "user" : la session est une Session de Vérification des utilisateurs (KYC). La réponse contient les tableaux de fonctionnalités propres aux utilisateurs.
  • "business" : la session est une Session de Vérification d’entreprise (KYB). La réponse contient les tableaux de fonctionnalités propres aux entreprises.
Utilisez ce champ pour traiter chaque réponse selon sa structure.
Les valeurs de l’énumération sont les identifiants courts "user" et "business", que nous gardons courts pour la commodité de l’API. Les noms complets Vérification des utilisateurs (KYC) et Vérification d’entreprise (KYB) sont utilisés dans toute la documentation, par souci de clarté.

Tableaux de fonctionnalités selon le type

Les tableaux de fonctionnalités présents dans une décision dépendent du type. Les champs absents d’un type n’apparaissent tout simplement pas dans la réponse (ni null, ni valeur de remplacement) :

Champs de premier niveau communs

Chaque session (les deux types) contient ces champs :

Endpoints concernés

Les endpoints suivants acceptent les deux types. Aucun chemin /v3/business-session/* distinct n’existe.

Fonctionnement des recherches

Les sessions de Vérification des utilisateurs (KYC) et de Vérification d’entreprise (KYB) sont deux types distincts. Les identifiants sont des UUID, de sorte que les collisions sont impossibles. Lorsque vous appelez un endpoint avec un session_id, Didit :
  1. Recherche l’identifiant dans la table des Vérifications des utilisateurs en premier (cela couvre la majorité du trafic).
  2. Se rabat sur la table des Vérifications d’entreprise si l’identifiant n’y figure pas.
  3. Renvoie une erreur 404 si aucune des deux tables ne contient de correspondance.
Vous n’avez jamais à indiquer à l’API le type recherché.

Les statuts sont identiques

Les valeurs de statut sont les mêmes pour les deux types, et l’API les renvoie exactement tels qu’ils sont écrits ici : "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User". La correspondance est exacte et sensible à la casse. Consultez la référence complète des statuts de vérification.

Webhooks

Les événements webhook contiennent déjà un champ session_kind afin que vos gestionnaires de webhooks puissent répartir le traitement par type : Consultez webhooks pour la vérification de signature et le comportement des nouvelles tentatives, ainsi que webhooks KYB pour le catalogue des événements de Vérification d’entreprise (KYB).

Étapes suivantes

Créer une session

Démarrez une vérification : Vérification des utilisateurs ou Vérification d’entreprise (KYB).

Récupérer une session

Récupérez la décision. Fonctionne pour les deux types.

Lister les sessions

Filtrez par session_kind.

Mettre à jour le statut

Approuvez, refusez, examinez ou soumettez de nouveau.

Générer un PDF

Rapports PDF par type.

Partager et importer

Transférez des sessions entre applications.
Dernière modification le 7 novembre 2026