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

# Compartir KYC por API: verificación reutilizable

> Didit permite compartir datos de verificación entre socios de confianza por API, con tokens de corta duración, y evita repetir el KYC.

## Cómo funciona

Supongamos que un usuario `A` superó la verificación de usuario en `Service X` y ahora se está registrando en el socio `Service Y`. Si `Service X` acepta compartir la información sobre `A` con `Service Y`, el proceso es el siguiente:

1. **Generar el token para compartir (`Service X`)**: `Service X` llama a la API para generar un `share_token` seguro y de corta duración para la sesión de verificación de un usuario concreto. Este token está destinado exclusivamente a `Service Y`. Consulta la referencia de la API: [Share Session API](https://docs.didit.me/es/sessions-api/share-session/share.md).

2. **Enviar el token al socio (`Service X` -> `Service Y`)**: `Service X` transmite de forma segura el `share_token` generado a `Service Y` a través de un canal de backend acordado previamente.

3. **Importar la sesión (`Service Y`)**: `Service Y` usa el `share_token` recibido para llamar a la API e importar los datos del usuario. Esto crea una copia completa de la sesión de verificación, con todos los documentos y comprobaciones, dentro del propio entorno de `Service Y`. Consulta la referencia de la API: [Import Shared Session API](https://docs.didit.me/es/sessions-api/share-session/import.md).

### Opciones de importación

Al importar una sesión, `Service Y` decide cómo gestionar los resultados:

* **`trust_review`**: este parámetro booleano determina si `Service Y` confía en la revisión y en el estado final (`Approved`/`Declined`) de `Service X`.
  * `true`: la sesión se copia con su estado original. El usuario queda dado de alta (o rechazado) al instante en `Service Y`.
  * `false`: los datos de la sesión se copian, pero el estado se establece automáticamente en `In Review`. Así, `Service Y` puede usar los documentos y datos recopilados, pero llevar a cabo su propio proceso de revisión interna para tomar una decisión final.
* **`workflow_id`**: `Service Y` debe indicar cuál de sus propios flujos de verificación (workflows) se asocia a la sesión importada.
* **`vendor_data`**: `Service Y` puede asignar su propio identificador interno de usuario a la sesión importada.

### Consideraciones importantes

* **Solo sesiones finalizadas**: solo se puede generar un token para compartir en sesiones con un estado finalizado (`Approved`, `Declined`, `In Review`).
* **Sin duplicados**: una sesión concreta solo se puede importar una vez en una aplicación asociada determinada. Los intentos posteriores se rechazarán.

***

## KYC reutilizable frente a compartir KYC mediante API

Aunque ambas funciones facilitan la reutilización de la identidad, tienen propósitos distintos:

| Función | KYC reutilizable controlado por el usuario | Compartir KYC mediante API (intercambio B2B) |
| - | - | - |
| **¿Quién lo inicia?** | El usuario final, durante el onboarding. | La empresa, mediante una llamada a la API entre servidores. |
| **Consentimiento** | El usuario da su consentimiento explícito para compartir sus datos en cada reutilización. | El consentimiento suele gestionarse en los términos de servicio acordados entre el usuario y la empresa inicial. Es obligatorio un acuerdo claro de intercambio de datos entre las empresas asociadas. |
| **Flujo de datos** | El Didit ID del usuario permite compartir los datos directamente con la nueva aplicación. | `Service X` comparte los datos con `Service Y` mediante un token seguro. |
| **Caso de uso** | Un usuario que quiere registrarse rápidamente en varios servicios no relacionados entre sí. | Ecosistemas de socios, grupos de servicios financieros o conglomerados en los que la identidad de un usuario debe poder usarse en distintas plataformas relacionadas. |

***

> ## ❗️ Importante: restricciones al intercambio de datos
>
> Compartir datos personales de usuarios entre distintas organizaciones está sujeto a estrictos requisitos legales y regulatorios. Antes de usar esta función, tu organización es responsable de garantizar el pleno cumplimiento de todas las leyes de protección de datos aplicables, como el RGPD en la Unión Europea y el UK GDPR en el Reino Unido.
>
> Debes:
>
> 1. **Establecer una base jurídica**: asegúrate de contar con una base jurídica legítima para compartir los datos. Esto suele requerir un acuerdo claro de intercambio de datos entre tu organización y la organización asociada.
> 2. **Garantizar el consentimiento del usuario**: confirma que tus usuarios han sido debidamente informados y han dado su consentimiento para que sus datos se compartan con tus socios, según lo establecido en tus términos de servicio y tu política de privacidad.
> 3. **Gestionar adecuadamente las transferencias internacionales**: si los datos se transfieren entre países (por ejemplo, de la UE a un país fuera de la UE), debes garantizar que existan las salvaguardas adecuadas que exige la ley.
>
> Didit ofrece la capacidad técnica para compartir datos, pero tu organización y tus socios son los únicos responsables de todas las obligaciones legales y de cumplimiento relacionadas con los datos que compartan. Te recomendamos encarecidamente consultar con tu asesor jurídico antes de implementar esta función.


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