Аутентификация
Все эндпоинты API управления используют ваш API-ключ приложения. В URL не нужны UUID организации и приложения: приложение определяется по вашему ключу.Сценарии
Сценарии определяют, через какие шаги верификации проходят ваши пользователи (сканирование документа, проверка живости, сравнение лиц, AML-скрининг и т. д.). Каждый сценарий представляет собой многоразовую конфигурацию, которую вы прикрепляете к сессиям.GET
Список всех сценариев вашего приложения. Возвращает функции каждого сценария, пороговые значения и признак того, является ли он сценарием по умолчанию.
POST
Создание нового сценария. Укажите, какие функции верификации включить, задайте пороговые значения, настройте допустимые типы документов и другие параметры.
GET
Получение полных сведений о конкретном сценарии, включая настройки всех функций и пороговые значения.
PATCH
Обновление конфигурации сценария. Можно изменить настройки любой функции, пороговые значения или допустимые документы.
DELETE
Удаление сценария. Сессии, которые уже используют этот сценарий, не затрагиваются.
Быстрый пример: создание сценария
Значение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.