Перейти к основному содержанию

Аутентификация

Все эндпоинты API управления используют ваш API-ключ приложения. В URL не нужны UUID организации и приложения: приложение определяется по вашему ключу.
Нет API-ключа? Зарегистрируйтесь программно с помощью двух вызовов API.

Сценарии

Сценарии определяют, через какие шаги верификации проходят ваши пользователи (сканирование документа, проверка живости, сравнение лиц, AML-скрининг и т. д.). Каждый сценарий представляет собой многоразовую конфигурацию, которую вы прикрепляете к сессиям.
GET
Список всех сценариев вашего приложения. Возвращает функции каждого сценария, пороговые значения и признак того, является ли он сценарием по умолчанию.
POST
Создание нового сценария. Укажите, какие функции верификации включить, задайте пороговые значения, настройте допустимые типы документов и другие параметры.
GET
Получение полных сведений о конкретном сценарии, включая настройки всех функций и пороговые значения.
PATCH
Обновление конфигурации сценария. Можно изменить настройки любой функции, пороговые значения или допустимые документы.
DELETE
Удаление сценария. Сессии, которые уже используют этот сценарий, не затрагиваются.
Мы настоятельно рекомендуем создавать и настраивать сценарии в Бизнес-консоли. Визуальный конструктор сценариев предоставляет шаблоны, настройку функций перетаскиванием, параметры документов, подстройку пороговых значений и предпросмотр, и всё это без написания кода. API используйте только для автоматизации или программного управления сценариями.

Быстрый пример: создание сценария

Значение workflow_type определяет базовый набор функций. Отдельные функции включаются и выключаются флагами is_*_enabled.
Доступные значения workflow_type: kyc, kyb, adaptive_age_verification, biometric_authentication, address_verification, questionnaire_verification, email_verification, phone_verification. Для сценариев kyc верификация личности включается автоматически, отдельный флаг для неё не нужен. Используйте флаги is_*_enabled, чтобы добавить или убрать дополнительные функции: сравнение лиц, проверку живости, AML-скрининг, NFC, проверку телефона, проверку электронной почты, подтверждение адреса, анализ устройства и IP и другие. Затем используйте сценарий при создании сессий:

Анкеты

Пользовательские формы, которые можно добавить в сценарии верификации, чтобы собирать у пользователей дополнительную информацию.
GET
Список всех анкет.
POST
Создание новой анкеты с пользовательскими вопросами, логикой ветвления и переводами.
GET
Получение сведений об анкете, включая все вопросы и структуру формы.
PATCH
Обновление анкеты.
DELETE
Удаление анкеты.

Пользователи

Управление верифицированными лицами (пользователями) в вашем приложении. Каждый пользователь идентифицируется строкой vendor_data, которую вы передаёте при создании сессий.
GET
Список всех пользователей вашего приложения, включая их статус верификации и историю сессий.
GET
Получение сведений о пользователе по вашему идентификатору vendor_data.
PATCH
Обновление метаданных пользователя.
POST
Пакетное удаление пользователей. Тело запроса: {"vendor_data_list": ["user-1", "user-2"]} или {"delete_all": true}. Также очищает все биометрические шаблоны, сохранённые для этих пользователей.

Биометрические шаблоны

Биометрические шаблоны лица без изображений, которые приложение, давшее на это согласие, сохраняет после удаления сессий. См. Биометрические шаблоны.
GET
Постраничный список с фильтрами (vendor_data, vendor_user_uuid, status, source_type, retained_from, retained_to, ordering).
GET
Количество шаблонов с теми же фильтрами.
GET
Один шаблон: пользователь-владелец, ссылка на источник, срок действия, инструкция и статус.
DELETE
Удаление одного шаблона. Возвращает {"uuid": "...", "outcome": "purged" | "already_purged"}.
POST
Массовая очистка. Тело запроса: {"template_uuids": [...]} или {"delete_all": true} вместе с необязательными фильтрами.

Операции с сессиями

POST
Пакетное удаление сессий. Требует delete:sessions. Тело запроса: {"session_numbers": ["1", "2", "3"]} или {"delete_all": true} (сузьте delete_all с помощью фильтров списка сессий с префиксом filter_, например filter_status), а также необязательные retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction и instruction_id. Для 20 или менее подходящих сессий возвращается 200 с face_retention_outcome для каждой сессии; при большем количестве возвращается 202 с заданием на удаление.
GET
Ход выполнения и итоговые показатели результатов массового удаления сессий, которое вернуло 202.
GET
Список проверок и журнал активности для сессии.
POST
Добавление заметки к проверке или изменение статуса сессии.

Биллинг

GET
Получить текущий баланс кредитов и настройки автопополнения.
POST
Создать сессию оплаты Stripe Checkout для пополнения баланса кредитов. Каждое пополнение составляет от $50 до $20,000 и зачисляется по номинальной стоимости.

Списки (списки блокировки, разрешённые списки и пользовательские)

Управление типизированными списками для блокировки, разрешения и пользовательских условий сценария. Полную документацию см. в документации по Lists API.
GET
Получить все списки приложения (списки блокировки, разрешённые списки и пользовательские).
POST
Добавить запись в список. Поддерживает reference_session_id для автоматического извлечения данных из сессии и reference_object_uuid для отслеживания связи с транзакциями, пользователями и компаниями.
DELETE
Удалить запись из списка.
POST
Загрузить изображение лица в список блокировки лиц (base64).

Настройка webhook

GET
Получить текущую конфигурацию webhook, включая URL, версию, секретный ключ для проверки подписей webhook, а также политику хранения данных и биометрических шаблонов приложения. Ответ также содержит allowed_domains, которое описано ниже, в разделе PATCH /v3/webhook/.
PATCH
Обновить URL webhook, версию или перевыпустить секретный ключ. Установите rotate_secret_key: true, чтобы сгенерировать новый секрет webhook (старый сразу становится недействительным). Также задаёт политику хранения приложения: data_retention_months и face_retention_policy (delete_with_session по умолчанию или retain_until_user_deleted). Когда хранение включено, обязательно указывается конечное значение face_retention_days (1–3650). См. Хранение биометрических шаблонов. Также регистрирует allowed_return_hosts: до 20 имён хостов (например, app.example.com) без схемы, порта, пути и символа подстановки, на которые верификация через Digital ID wallet API может вернуть пользователя по HTTPS. Новый список заменяет зарегистрированный. Домен White label вашего приложения разрешён всегда.Также задаёт allowed_domains: до 50 веб-источников (например, https://app.example.com), в которые может встраиваться размещённая страница верификации и на которые она может вернуть пользователя с помощью callback сессии. Каждая запись состоит из схемы, хоста и необязательного порта, без пути, query-параметров и символа подстановки. Используйте https. http принимается только для localhost, 127.0.0.1 и ::1. Didit сохраняет каждый источник в нижнем регистре без порта по умолчанию и возвращает список в allowed_domains. Некорректная запись завершается ошибкой 400 для поля allowed_domains. Новый список заменяет зарегистрированный, а пустой список снимает ограничение. Пока список не пуст, POST /v3/session/ отклоняет веб-callback, которого в нём нет, с ошибкой 400, а размещённая страница верификации не перенаправляет пользователя на сохранённый или заданный по умолчанию в сценарии callback, если его нет в списке. На пользовательские URL-схемы (глубокие ссылки в приложении) и серверные вызовы API это не распространяется.Если вы передаёте endpoints, каждый адрес назначения webhook, которого нет в списке, удаляется безвозвратно вместе с секретом подписи и всем журналом доставки, точно так же, как при DELETE /v3/webhook/destinations/{destination_uuid}/. Это действие нельзя отменить. Чтобы управлять адресами назначения по одному, используйте endpoint’ы адресов назначения webhook.

Полная сводка endpoint’ов API

Последнее изменение 7 ноября 2026 г.