Перейти к основному содержанию
Управление основными сущностями пользователей выполняется через публичные endpoint’ы по пути /v3/users/. Вложения профиля, например загрузка импортированного лица, выполняются по пути organization/application с didit_internal_id. Эта страница даёт концептуальный обзор. Полные схемы запросов и ответов см. в справочнике API.

Список пользователей

GET /v3/users/ Возвращает постраничный список пользователей вашего приложения. Поддерживаются фильтры по статусу, поиску, диапазону дат и другим параметрам.
Сценарии использования:
  • Ежедневная синхронизация части пользователей с вашим хранилищем данных.
  • Поиск помеченных пользователей для очереди аналитика.
  • Поиск пользователей по отображаемому имени.

Получение пользователя

GET /v3/users/{vendor_data}/ Получает одного пользователя по vendor_data. Возвращает полную модель данных, включая агрегированные счётчики.
vendor_data в URL чувствителен к регистру. Всегда передавайте точное значение, которое использовали при создании сессии.

Создание пользователя

POST /v3/users/create/ Создаёт сущность пользователя до запуска любой сессии. Это полезно для:
  • Заполнения метаданных или пользовательских полей до того, как клиент пройдёт верификацию.
  • Установки начального статуса (например, FLAGGED, пока ваша команда онбординга проверяет документы вручную).
  • Предварительной загрузки пользователей из существующей базы данных, чтобы с первого дня иметь полный список.
Если пользователь с таким vendor_data уже существует, вызов возвращает ошибку конфликта. Для обновления используйте PATCH. Также можно передать контактные данные: first_name и last_name (объединяются в full_name, если вы не передали его), email, phone_number и country. Didit сохраняет email и phone_number в metadata.contact, а country в metadata.address. Чтобы пригласить человека пройти верификацию в том же вызове, добавьте send_verification_link: true вместе с email и workflow_id. Didit создаёт для него сессию верификации по этому сценарию и отправляет ему ссылку по электронной почте. Ответ verification_link содержит session_id, session_number, status, url, workflow_id и email сессии. Если ссылку не запрашивали, поле равно null. Проверки и ошибки см. в разделе Создание пользователя.

Загрузка импортированного лица

POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/ Прикрепляет доверенное изображение лица к существующему профилю пользователя. Это правильный следующий шаг, если вы импортируете пользователей от другого провайдера и хотите, чтобы Didit сохранил подтверждение их лица до первой сессии Didit.
См. Загрузка лица пользователя: поля запроса, ограничения, endpoint’ы для получения и удаления, а также различие между загрузкой лица и списком блокировки.

Обновление пользователя

PATCH /v3/users/{vendor_data}/ Обновляет изменяемые поля профиля. Большинство полей, полученных из проверенных сессий, доступны только для чтения. Попытка изменить их через PATCH либо будет проигнорирована, либо отмечена в журнале аудита. Изменяемые поля: display_name, metadata, tags. Доступны только для чтения после верификации: full_name, date_of_birth, portrait_image, все агрегированные счётчики, карта features.
Генерирует webhook user.data.updated с массивом changed_fields.

Изменение статуса

PATCH /v3/users/{vendor_data}/update-status/ Переводит пользователя между статусами ACTIVE, FLAGGED и BLOCKED. Изменения статуса применяются к будущим сессиям и транзакциям.
Генерирует webhook user.status.updated.

Удаление пользователей (пакетное)

POST /v3/users/delete/ Удаляет одного или нескольких пользователей. Записи пользователей удаляются безвозвратно вместе со всеми биометрическими шаблонами, сохранёнными для них после удаления сессии. Их сессии верификации этим endpoint’ом не удаляются: они сохраняются, а связь с пользователем очищается. Удалите их с помощью Удаление сессии или Пакетное удаление сессий. Транзакции тоже не затрагиваются. Удалите их в Console.
Выбирайте пользователей по vendor_data_list, по didit_internal_id_list или сразу по обоим спискам. Либо передайте delete_all: true, чтобы удалить всех пользователей приложения. Пакетные параметры filter_* из Console отклоняются с кодом 400, а не игнорируются, поэтому сужение выборки никогда не превратится в полную очистку. Возвращает количество в виде {"deleted": <int>}, а не результат по каждому элементу. Идентификаторы, которые ни с чем не совпали, молча пропускаются. Поэтому, если хотите сверить deleted с числом отправленных идентификаторов, отправляйте список без дубликатов.

Модель разрешений

API-ключи принадлежат одному приложению. Основной секретный ключ и ключи с полным доступом могут вызывать все endpoint’ы /v3/users/* этого приложения, включая delete. API-ключ с ограниченными правами должен иметь доступ Люди (users): чтение для endpoint’ов GET, а для создания, обновления, изменения статуса и удаления требуется право на запись. Создание пользователя с send_verification_link: true также требует права записи для Сессии, так как при этом создаётся сессия и отправляется её ссылка по электронной почте. Ключ без нужного доступа возвращает 403. Ключ, ограниченный отдельными сценариями или одобренными сессиями, вообще не может обращаться к endpoint’ам /v3/users/*. Роли относятся к Console. Ресурс разрешений users и его утверждения определяют, что может делать член команды в Console, а для запросов с API-ключами они не проверяются. Матрицу см. в разделе Роли и разрешения. Чтобы не позволить сервису удалять пользователей, выдайте ему ключ с доступом Люди только на чтение или без доступа к Люди.

Лимиты запросов и идемпотентность

  • На все endpoint’ы /v3/users/* распространяются стандартные лимиты запросов.
  • create не идемпотентен: повторная отправка с тем же vendor_data возвращает конфликт. Устраняйте дубликаты на своей стороне или всегда сначала выполняйте GET.
  • delete идемпотентен: удаление уже удалённого пользователя ничего не меняет.

Webhooks, запускаемые этими операциями

Следующие шаги

Модель данных

Полный справочник полей.

API списка

Схема GET /v3/users/.

API создания

Схема POST /v3/users/create/.

Загрузка лица

Прикрепление импортированных изображений лица к профилям пользователей.
Последнее изменение 7 ноября 2026 г.