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

# API Sessions de vérification KYC et KYB unifiée

> Didit : API Sessions unifiée pour KYC et KYB sur un endpoint. Tarif à l'usage, inférence sous 2 s, 220+ pays, 14,000+ documents, $10 offerts/mois.

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 :

| Type | Ce qu'elle vérifie | Le payload de décision comprend |
| - | - | - |
| **Session de Vérification des utilisateurs (KYC)** | Une personne physique | Vérification d'identité, détection du vivant, correspondance faciale, justificatif de domicile (POA), vérification NFC, validation en base de données, vérification du téléphone, vérification de l'e-mail, filtrage AML, questionnaires, analyse de l'appareil et de l'IP |
| **Session de Vérification d'entreprise (KYB)** | Une entreprise ou une entité juridique | Contrôle au registre des sociétés, personnes clés (dirigeants et bénéficiaires effectifs), vérifications de documents, vérification du téléphone, vérification de l'e-mail, filtrage AML, questionnaires, analyse de l'appareil et de l'IP |

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 parcours hébergé ou la création de vos propres écrans - Didit Academy](https://www.youtube.com/embed/LzGe-dMWjUw?start=334\&rel=0\&playsinline=1)

## Le type est déterminé par le workflow

Lorsque vous [créez une session](https://docs.didit.me/fr/sessions-api/create-session.md), 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 :

```json theme={null}
{
  "session_id": "...",
  "session_kind": "user",
  ...
}
```

* `"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.

> [!NOTE]
>
> 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) :

| Tableau de fonctionnalités | Vérification des utilisateurs (KYC) | Vérification d'entreprise (KYB) |
| - | :-: | :-: |
| `id_verifications` | ✅ | — |
| `liveness_checks` | ✅ | — |
| `face_matches` | ✅ | — |
| `nfc_verifications` | ✅ | — |
| `poa_verifications` | ✅ | — |
| `database_validations` | ✅ | — |
| `registry_checks` | — | ✅ |
| `document_verifications` | — | ✅ |
| `key_people_checks` | — | ✅ |
| `aml_screenings` | ✅ | ✅ |
| `phone_verifications` | ✅ | ✅ |
| `email_verifications` | ✅ | ✅ |
| `questionnaire_responses` | ✅ | ✅ |
| `ip_analyses` | ✅ | ✅ |
| `reviews` | ✅ | ✅ |
| `contact_details` | ✅ | ✅ |

## Champs de premier niveau communs

Chaque session (les deux types) contient ces champs :

| Champ | Description |
| - | - |
| `session_id` | UUID de la session |
| `session_kind` | `"user"` (Vérification des utilisateurs (KYC)) ou `"business"` (Vérification d'entreprise (KYB)) |
| `session_number` | Numéro séquentiel au sein de l'application |
| `session_url` | URL de la page de vérification hébergée |
| `status` | Statut global de la session : `APPROVED`, `DECLINED`, `IN_REVIEW`, `IN_PROGRESS`, etc. |
| `workflow_id` | UUID du workflow utilisé |
| `vendor_data` | Votre identifiant de l'entité. [En savoir plus](https://docs.didit.me/fr/entities/vendor-data-linking.md) |
| `metadata` | JSON libre que vous avez joint à la création |
| `callback` | URL de rappel facultative |
| `features` | Liste des fonctionnalités exécutées par le workflow, séparées par des virgules |
| `expected_details` | Payload facultatif de données attendues, pour la validation croisée |
| `created_at`, `expires_at` | Horodatages |

## Endpoints concernés

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

| Endpoint | Fonctionne pour |
| - | - |
| [`POST /v3/session/`](https://docs.didit.me/fr/sessions-api/create-session) | Crée une session de Vérification des utilisateurs (KYC) ou de Vérification d'entreprise (KYB) selon le type de workflow |
| [`GET /v3/session/{id}/decision/`](https://docs.didit.me/fr/sessions-api/retrieve-session) | Récupère l'un ou l'autre type : l'aiguillage se fait sur `session_id` |
| [`GET /v3/sessions/`](https://docs.didit.me/fr/sessions-api/list-sessions) | Liste l'un ou l'autre type. Utilisez le paramètre de requête `session_kind` pour filtrer |
| [`PATCH /v3/session/{id}/update-status/`](https://docs.didit.me/fr/sessions-api/update-status) | Met à jour l'un ou l'autre type |
| [`DELETE /v3/session/{id}/delete/`](https://docs.didit.me/fr/sessions-api/delete-session) | Supprime l'un ou l'autre type |
| [`GET /v3/session/{id}/generate-pdf/`](https://docs.didit.me/fr/sessions-api/generate-pdf) | Génère un PDF pour l'un ou l'autre type : il utilise le modèle de Vérification des utilisateurs (KYC) ou de Vérification d'entreprise (KYB) |
| [`POST /v3/session/{id}/share/`](https://docs.didit.me/fr/sessions-api/share-session/share) | Le jeton de partage inclut `session_kind` |
| [`POST /v3/session/import-shared/`](https://docs.didit.me/fr/sessions-api/share-session/import) | Importe l'un ou l'autre type et conserve `session_kind` provenant du jeton |

## 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](https://docs.didit.me/fr/integration/verification-statuses.md).

## 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 :

| Événement | Type | Déclenché lorsque |
| - | - | - |
| `status.updated` | Les deux | Le statut d'une session a changé. Le payload contient `session_kind: "user"` ou `"business"`. |
| `data.updated` | Les deux | Les données d'une session ont changé (résultats des fonctionnalités, actualisation du registre des sociétés, surveillance AML continue). Le payload contient `session_kind`. |
| `business.status.updated` / `business.data.updated` | Entité d'entreprise | L'entité d'entreprise liée a changé. |
| `user.status.updated` / `user.data.updated` | Entité utilisateur | L'entité utilisateur liée a changé. |

Consultez [webhooks](https://docs.didit.me/fr/integration/webhooks.md) pour la vérification de signature et le comportement des nouvelles tentatives, ainsi que [webhooks KYB](https://docs.didit.me/fr/business-verification/webhooks.md) pour le catalogue des événements de Vérification d'entreprise (KYB).

## Étapes suivantes

> [card] [Créer une session](https://docs.didit.me/fr/sessions-api/create-session.md)
>
> Démarrez une vérification : Vérification des utilisateurs ou Vérification d'entreprise (KYB).

> [card] [Récupérer une session](https://docs.didit.me/fr/sessions-api/retrieve-session.md)
>
> Récupérez la décision. Fonctionne pour les deux types.

> [card] [Lister les sessions](https://docs.didit.me/fr/sessions-api/list-sessions.md)
>
> Filtrez par `session_kind`.

> [card] [Mettre à jour le statut](https://docs.didit.me/fr/sessions-api/update-status.md)
>
> Approuvez, refusez, examinez ou soumettez de nouveau.

> [card] [Générer un PDF](https://docs.didit.me/fr/sessions-api/generate-pdf.md)
>
> Rapports PDF par type.

> [card] [Partager et importer](https://docs.didit.me/fr/sessions-api/share-session/overview.md)
>
> Transférez des sessions entre applications.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.