Привязка vendor_data: связывание ID с сущностями

vendor_data — это идентификатор, который вы передаёте в каждой сессии и каждой транзакции, чтобы связать их с сущностью User или Business. Это самое важное поле для агрегации сущностей: если оно задано правильно, все последующие функции (история профиля, мониторинг транзакций, применение списков блокировки, постоянный AML-мониторинг) работают без сбоев.

Что это такое

vendor_data — это строка, которую выбираете вы. Didit рассматривает её как непрозрачный идентификатор и не интерпретирует её содержимое. Типичные значения:

Ваша система	Подходящие значения `vendor_data`
Внутренняя база пользователей	`user_1234`, `uuid-v4` пользователя
Идентификатор для клиентов	`CUST-2026-00042`, хеш email
Мультитенантный SaaS	`tenant_acme:user_1234`
B2B-платформа	`company-hq-global`, `tax-id-US-123456789`

Не передавайте персональные данные (email, номера телефонов, необработанные налоговые номера) в vendor_data. Хешируйте их или добавляйте префикс. vendor_data появляется в payload webhook-уведомлений и хранится бессрочно, пока существует сущность.

Как это связывает данные

Когда вы отправляете сессию или транзакцию со значением vendor_data:

Didit ищет в вашем приложении сущность с этим vendor_data.
Если она существует, новый объект привязывается к этой сущности.
Если её нет, Didit создаёт сущность (со status: ACTIVE) и привязывает к ней новый объект.

Это относится к:

POST /v3/session/: сессии KYC и верификации бизнеса (KYB)
POST /v3/transactions/: транзакции (для заявителя и контрагента)
Полям applicant.vendor_data и counterparty.vendor_data внутри payload транзакций

Уникальность и область действия

vendor_data уникален в пределах приложения, а не во всём Didit:

Область	Гарантия уникальности
В пределах одного приложения	`vendor_data` уникален для каждого типа сущности (User и Business — разные пространства имён)
В приложениях вашей организации	`vendor_data` не используется совместно: одно и то же значение в двух приложениях относится к двум разным сущностям
В разных организациях	Не используется совместно: у каждой организации собственные таблицы сущностей

Это значит, что одно и то же vendor_data можно использовать в стейджинговом и в продакшн-приложении без конфликтов. Также можно иметь User user-42 и Business user-42 без конфликта, хотя для ясности это не рекомендуется.

Что происходит, если не передать `vendor_data`

Сессию можно создать и без vendor_data. В этом случае:

Для сессии сущность не создаётся.
Сессия остаётся без привязки: она не появится ни в одном профиле User или Business.
Позже найти сессию по vendor_data нельзя, только по session_id.

Используйте этот подход только для анонимных или разовых верификаций, где агрегация сущностей не нужна. Для любой интеграции, которая включает повторную верификацию, транзакции или постоянный мониторинг, всегда передавайте vendor_data.

Пример: создание сущности заранее, затем запуск сессий

# 1. Pre-create the User with initial metadata
curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data": "user-42",
    "display_name": "Jane Doe",
    "metadata": { "tier": "premium", "signup_date": "2026-04-01" }
  }'

# 2. Create a User Verification (KYC) session for the same user
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "wf_kyc_standard",
    "vendor_data": "user-42"
  }'

# 3. Later, submit a transaction tied to the same user
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "txn_id": "tx-0001",
    "direction": "OUTBOUND",
    "amount": "500.00",
    "currency": "EUR",
    "applicant": { "vendor_data": "user-42" },
    "counterparty": { "name": "Acme Corp" }
  }'

Все три вызова привязаны к одной сущности User. Когда вы позже выполните GET /v3/users/user-42/, вы увидите количество сессий, счётчики одобренных и отклонённых верификаций, связанные транзакции и последние данные профиля.

Миграция внешних идентификаторов

Если вы переходите на Didit с другого KYC-провайдера, передавайте существующие стабильные идентификаторы пользователей как vendor_data с первого дня. Так будет проще:

Сверять данные Didit с вашей внутренней базой.
Массово загрузить исторических пользователей через импорт CSV в консоли до запуска любых сессий.
Сохранить связи, если позже вы перейдёте на Didit для мониторинга транзакций.

Правила, соглашения и рекомендации

Правило	Почему
Выберите один канонический идентификатор для каждой сущности и никогда его не меняйте	Изменение создаёт новую сущность и оставляет историю без связи
Добавляйте к значениям `vendor_data` префикс по типу сущности (`user_...`, `biz_...`)	Предотвращает случайные конфликты между пространствами имён в вашем коде
Сохраняйте регистр `vendor_data` неизменным	Didit не приводит регистр к единому виду
Длина `vendor_data` должна быть меньше 128 символов	Комфортно помещается в индексы базы данных
Никогда не раскрывайте персональные данные в открытом виде	`vendor_data` появляется в webhook, журналах аудита и ответах API

Что дальше

Обзор Users

Подробно о сущностях User и операциях с ними.

Обзор Businesses

Подробно о сущностях Business и операциях с ними.

Создание сессии

Запустите верификацию для vendor_data.

Создание транзакции

Отправьте транзакцию, связанную с сущностью.

Обзор

Цены

Сценарии и верификация

Проверка и операции

Сущности (пользователи и компании)

Настройки и кастомизация

Безопасность и комплаенс

Didit Academy

Ресурсы

Привязка vendor_data: связывание ID с сущностями

Что это такое

Как это связывает данные

Уникальность и область действия

Что происходит, если не передать `vendor_data`

Пример: создание сущности заранее, затем запуск сессий

Миграция внешних идентификаторов

Правила, соглашения и рекомендации

Что дальше

Обзор Users

Обзор Businesses

Создание сессии

Создание транзакции

​Что это такое

​Как это связывает данные

​Уникальность и область действия

​Что происходит, если не передать vendor_data

​Пример: создание сущности заранее, затем запуск сессий

​Миграция внешних идентификаторов

​Правила, соглашения и рекомендации

​Что дальше

Обзор Users

Обзор Businesses

Создание сессии

Создание транзакции

Что это такое

Как это связывает данные

Уникальность и область действия

Что происходит, если не передать `vendor_data`

Пример: создание сущности заранее, затем запуск сессий

Миграция внешних идентификаторов

Правила, соглашения и рекомендации

Что дальше