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

# Передача KYC через API: многоразовый KYC

> Didit позволяет безопасно передавать данные верификации партнерам через API с помощью временных токенов без повторного KYC.

## Как это работает

Предположим, пользователь `A` прошёл проверку пользователей в `Service X` и теперь регистрируется у партнёра `Service Y`. Если `Service X` согласен передать данные о `A` сервису `Service Y`, это можно сделать следующим образом:

1. **Генерация share token (`Service X`)**: `Service X` выполняет вызов API для генерации защищённого короткоживущего `share_token` для сессии верификации конкретного пользователя. Этот token предназначен исключительно для использования сервисом `Service Y`. См. Справочник API: [Share Session API](https://docs.didit.me/ru/sessions-api/share-session/share.md).

2. **Передача token партнёру (`Service X` -> `Service Y`)**: `Service X` безопасно передаёт сгенерированный `share_token` сервису `Service Y` по предварительно согласованному серверному каналу.

3. **Импорт сессии (`Service Y`)**: `Service Y` использует полученный `share_token` для вызова API импорта данных пользователя. Это создаёт полную копию сессии верификации, включая все документы и проверки, в собственной среде `Service Y`. См. Справочник API: [Import Shared Session API](https://docs.didit.me/ru/sessions-api/share-session/import.md).

### Параметры импорта

При импорте сессии `Service Y` может управлять обработкой результатов с помощью следующих параметров:

* **`trust_review`**: этот булев параметр определяет, доверяет ли `Service Y` проверке и финальному статусу (`Approved`/`Declined`) от `Service X`.
  * `true`: сессия копируется с исходным статусом. Пользователь мгновенно проходит онбординг (или отклоняется) в `Service Y`.
  * `false`: данные сессии копируются, но статус автоматически устанавливается в `In Review`. Это позволяет `Service Y` использовать собранные документы и данные, но провести собственный внутренний процесс проверки для принятия окончательного решения.
* **`workflow_id`**: `Service Y` должен указать, с каким из его собственных сценариев верификации следует связать импортированную сессию.
* **`vendor_data`**: `Service Y` может присвоить импортированной сессии собственный внутренний идентификатор пользователя.

### Важные замечания

* **Только завершённые сессии**: share token можно сгенерировать только для сессий с завершённым статусом (`Approved`, `Declined`, `In Review`).
* **Без дубликатов**: конкретную сессию можно импортировать в данное партнёрское приложение только один раз. Последующие попытки будут отклонены.

***

## Многоразовый KYC в сравнении с передачей KYC через API

Хотя обе функции обеспечивают повторное использование данных идентификации, они служат разным целям:

| Функция | Управляемый пользователем Многоразовый KYC | Передача KYC через API (обмен B2B) |
| - | - | - |
| **Кто инициирует?** | Конечный пользователь в процессе онбординга. | Компания посредством межсерверного вызова API. |
| **Согласие** | Пользователь явно даёт согласие на передачу своих данных при каждом повторном использовании. | Согласие обычно регулируется пользовательским соглашением с первоначальной компанией. Требуется чёткое соглашение об обмене данными между компаниями-партнёрами. |
| **Поток данных** | Didit ID пользователя обеспечивает передачу данных напрямую в новое приложение. | `Service X` передаёт данные сервису `Service Y` через защищённый token. |
| **Вариант использования** | Пользователь хочет быстро зарегистрироваться в нескольких несвязанных сервисах. | Партнёрские экосистемы, группы финансовых сервисов или конгломераты, где идентификационные данные пользователя должны быть переносимыми между связанными платформами. |

***

> ## ❗️ Важно: ограничения на передачу данных
>
> Передача персональных данных пользователей между различными организациями регулируется строгими правовыми и нормативными требованиями. Перед использованием этой функции ваша организация несёт ответственность за обеспечение полного соответствия всем применимым законам о защите данных, таким как GDPR в Европейском союзе и UK GDPR в Великобритании.
>
> Вы должны:
>
> 1. **Установить законное основание**: убедитесь, что у вас есть законное основание для передачи данных. Часто для этого требуется явное соглашение об обмене данными между вами и вашей партнёрской организацией.
> 2. **Обеспечить согласие пользователя**: убедитесь, что ваши пользователи должным образом проинформированы и дали согласие на передачу своих данных вашим партнёрам, как указано в ваших условиях обслуживания и политике конфиденциальности.
> 3. **Корректно организовать трансграничную передачу**: если данные передаются через границу (например, из ЕС в страну, не входящую в ЕС), вы должны обеспечить применение надлежащих мер защиты в соответствии с требованиями законодательства.
>
> Didit предоставляет техническую возможность для обмена данными, но все юридические обязательства и обязательства по соблюдению требований, связанные с передаваемыми данными, лежат исключительно на вашей организации и ваших партнёрах. Мы настоятельно рекомендуем проконсультироваться с вашим юридическим консультантом перед внедрением этой функции.


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