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

# Partager un KYC via API : vérification réutilisable

> Partagez les données KYC entre partenaires via l'API Didit et éliminez les vérifications répétées grâce à des tokens de partage temporaires.

## Comment cela fonctionne

Supposons qu'un utilisateur `A` ait réussi la vérification des utilisateurs dans `Service X` et soit maintenant en train de s'inscrire auprès du partenaire `Service Y`. Si `Service X` accepte de partager les informations concernant `A` avec `Service Y`, cela peut être effectué de la manière suivante :

1. **Générer un token de partage (`Service X`)** : `Service X` effectue un appel API pour générer un `share_token` sécurisé à courte durée de vie pour la session de vérification d'un utilisateur spécifique. Ce token est destiné exclusivement à être utilisé par `Service Y`. Consultez la référence de l'API : [Share Session API](https://docs.didit.me/fr/sessions-api/share-session/share.md).

2. **Transmettre le token au partenaire (`Service X` -> `Service Y`)** : `Service X` transmet de manière sécurisée le `share_token` généré à `Service Y` via un canal backend préalablement convenu.

3. **Importer la session (`Service Y`)** : `Service Y` utilise le `share_token` reçu pour effectuer un appel API afin d'importer les données de l'utilisateur. Cela crée une copie complète de la session de vérification, y compris l'ensemble des documents et des contrôles, au sein du propre environnement de `Service Y`. Consultez la référence de l'API : [Import Shared Session API](https://docs.didit.me/fr/sessions-api/share-session/import.md).

### Options d'importation

Lors de l'importation d'une session, `Service Y` garde le contrôle sur la façon de traiter les résultats :

* **`trust_review`** : ce paramètre booléen détermine si `Service Y` fait confiance à l'examen et au statut final (`Approved`/`Declined`) de `Service X`.
  * `true` : la session est copiée avec le statut d'origine. L'utilisateur est immédiatement onboardé (ou refusé) sur `Service Y`.
  * `false` : les données de la session sont copiées, mais le statut est automatiquement défini sur `In Review`. Cela permet à `Service Y` d'utiliser les documents et données collectés tout en réalisant son propre processus d'examen interne pour prendre une décision finale.
* **`workflow_id`** : `Service Y` doit spécifier lequel de ses propres workflows de vérification associer à la session importée.
* **`vendor_data`** : `Service Y` peut attribuer son propre identifiant d'utilisateur interne à la session importée.

### Points importants à prendre en compte

* **Sessions terminées uniquement** : un token de partage ne peut être généré que pour les sessions ayant un statut terminé (`Approved`, `Declined`, `In Review`).
* **Aucun doublon** : une session spécifique ne peut être importée qu'une seule fois dans une application partenaire donnée. Les tentatives ultérieures seront rejetées.

***

## KYC réutilisable vs Partage de KYC via API

Bien que ces deux fonctionnalités facilitent la réutilisation de l'identité, elles répondent à des finalités différentes :

| Fonctionnalité | KYC réutilisable contrôlé par l'utilisateur | Partage de KYC via API (partage B2B) |
| - | - | - |
| **Qui initie le processus ?** | L'utilisateur final, pendant l'onboarding. | L'entreprise, via un appel API de serveur à serveur. |
| **Consentement** | L'utilisateur consent explicitement au partage de ses données à chaque réutilisation. | Le consentement est généralement géré dans les conditions d'utilisation acceptées par l'utilisateur auprès de l'entreprise initiale. Un accord clair de partage de données entre les entreprises partenaires est requis. |
| **Flux de données** | Le Didit ID de l'utilisateur facilite le partage de données directement avec la nouvelle application. | `Service X` partage des données avec `Service Y` via un token sécurisé. |
| **Cas d'usage** | Un utilisateur souhaitant s'inscrire rapidement à plusieurs services sans lien direct. | Écosystèmes de partenaires, groupes de services financiers ou conglomérats où l'identité d'un utilisateur doit être transférable entre plateformes associées. |

***

> ## ❗️ Important : restrictions relatives au partage de données
>
> Le partage de données personnelles d'utilisateurs entre différentes organisations est soumis à des exigences légales et réglementaires strictes. Avant d'utiliser cette fonctionnalité, votre organisation a la responsabilité de s'assurer d'être en totale conformité avec l'ensemble des lois applicables sur la protection des données, telles que le RGPD dans l'Union européenne et le UK GDPR au Royaume-Uni.
>
> Vous devez :
>
> 1. **Établir une base légale** : assurez-vous de disposer d'une base légale légitime pour le partage des données. Cela nécessite souvent un accord clair de partage de données entre vous et votre organisation partenaire.
> 2. **Garantir le consentement de l'utilisateur** : confirmez que vos utilisateurs ont été correctement informés et ont consenti au partage de leurs données avec vos partenaires, comme indiqué dans vos conditions d'utilisation et votre politique de confidentialité.
> 3. **Gérer les transferts internationaux de manière appropriée** : si des données sont transférées au-delà des frontières (par exemple, de l'UE vers un pays non-membre de l'UE), vous devez vous assurer que les garanties appropriées requises par la loi sont en place.
>
> Didit fournit les capacités techniques permettant le partage de données, mais votre organisation et vos partenaires demeurent seuls responsables de l'ensemble des obligations légales et de conformité liées aux données partagées. Nous vous recommandons vivement de consulter votre conseiller juridique avant d'implémenter cette fonctionnalité.


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