/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.
Обновление пользователя
PATCH /v3/users/{vendor_data}/
Обновляет изменяемые поля профиля. Большинство полей, полученных из проверенных сессий, доступны только для чтения. Попытка изменить их через PATCH либо будет проигнорирована, либо отмечена в журнале аудита.
Изменяемые поля: display_name, metadata, tags.
Доступны только для чтения после верификации: full_name, date_of_birth, portrait_image, все агрегированные счётчики, карта features.
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/.
Загрузка лица
Прикрепление импортированных изображений лица к профилям пользователей.