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 unworkflow_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.
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 unsession_id, Didit :
- Recherche l’identifiant dans la table des Vérifications des utilisateurs en premier (cela couvre la majorité du trafic).
- Se rabat sur la table des Vérifications d’entreprise si l’identifiant n’y figure pas.
- Renvoie une erreur 404 si aucune des deux tables ne contient de correspondance.
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 champsession_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.