Перейти к основному содержанию
This guide walks you through the complete flow for integrating Didit identity verification via the REST API: getting credentials, creating a session, presenting it to the user, and receiving results.

Шаг 1: Получение учётных данных

Есть два способа получить api_key:

Вариант A: программная регистрация (без браузера)

Лучше всего подходит для CI/CD и ИИ-агентов. Два вызова API, POST /programmatic/register/ и затем POST /programmatic/verify-email/, возвращают api_key прямо в ответе. → Полный процесс, правила пароля, срок действия JWT и политику блокировки см. в разделе Программная регистрация.

Вариант B: в консоли Didit

  1. Перейдите в Didit Console.
  2. Создайте организацию или выберите существующую.
  3. Перейдите в Settings → API & Webhooks.
  4. Скопируйте:
    • API Key: используется как заголовок x-api-key в каждом вызове верификации.
    • Webhook Secret Key: используется для проверки HMAC-подписей webhook.

Переменные окружения


Шаг 2: Создание сценария

Перед созданием сессий нужен сценарий верификации. Сценарии определяют, через какие шаги верификации проходят пользователи.

Создание в консоли

  1. Перейдите в Didit Console → Workflows
  2. Нажмите Create Workflow
  3. Выберите базовый шаблон:
  1. Добавьте необязательные функции:
  1. Скопируйте Workflow ID
Подробнее о параметрах настройки см. в документации по сценариям.

Шаг 3: Создание сессии верификации

Вызовите API, чтобы создать сессию для вашего пользователя.

Запрос

Параметры запроса

Полный пример со всеми параметрами

expected_details.expected_document_types ограничивает шаг верификации личности определенными типами документов: на экране выбора документа отображаются только запрошенные типы. Допустимые значения: P (паспорт), ID (национальное удостоверение личности), DL (водительское удостоверение), RP (вид на жительство), HIC (карта медицинского страхования), TC (налоговая карта), SSC (карта социального страхования). Значения не чувствительны к регистру и не повторяются; неизвестные значения возвращают 400. Полную схему см. в справочнике Create Session.

Ответ

201 Created:

Ключевые поля ответа

Идемпотентность. Если передан vendor_data и на последней опубликованной версии сценария уже существует незавершенная сессия (Not Started, In Progress, Resubmitted или Awaiting User) с тем же vendor_data, возвращается эта существующая сессия (все так же с кодом 201), а не создается дубликат. При этом ее callback и metadata обновляются новыми значениями, а status отражает статус существующей сессии.
Отсутствие x-api-key возвращает 403 с телом {"detail": "You do not have permission to perform this action."}, таким же, как у действительного ключа без разрешения. Неверный, отозванный или истекший ключ возвращает 401. Недостаточно кредитов: возвращается 400. Полную документацию см. в справочнике API Create Session.

Шаг 4: Проведение верификации для пользователя

Выберите, как показать пользователю процесс верификации:

Вариант A: нативный SDK (рекомендуется для мобильных приложений)

Используйте session_token с нативными SDK для интеграции камеры, NFC и биометрии. → iOS SDK · Android SDK · React Native · Flutter

Вариант B: встраиваемый iframe InContext (рекомендуется для веб-сайтов)

Встройте верификацию на свою страницу, используя url, полученный на шаге 3.
→ iframe InContext

Вариант C: перенаправление

Перенаправьте пользователя на URL верификации.
→ Веб-перенаправление

Вариант D: мобильный WebView

Для мобильных приложений без нативного SDK.
→ WebView в iOS и Android

Шаг 5: Получение результатов

Через webhook (рекомендуется)

Webhook уведомляет ваш сервер в реальном времени при изменении статуса верификации. Настройка:
  1. Создайте адрес назначения webhook в Консоли (API и вебхуки) или через POST /v3/webhook/destinations/ с webhook_version: "v3" и массивом subscribed_events (например, ["status.updated"])
  2. Сохраните secret_shared_key, который возвращается при создании: это секрет HMAC для всех вариантов подписи
  3. Реализуйте на своем сервере endpoint webhook
Пример payload webhook: Внутри decision каждый результат по отдельной функции передается как массив во множественном числе (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …): одна запись на каждый узел сценария. Это контракт V3, и его нельзя менять: никогда не пишите код, опирающийся на ключи nfc, id_verification или liveness в единственном числе.
Объект decision присутствует только тогда, когда status имеет значение Approved, Declined, In Review или Abandoned (событие Resubmitted содержит resubmit_info). Didit использует один и тот же event_id при повторных отправках и при отправке на несколько адресов назначения, поэтому по нему нужно строить идемпотентность. Все массивы во множественном числе и поля описаны в разделе Модели данных. Проверка подписи (X-Signature-V2, рекомендуется): X-Signature-V2 — это HMAC-SHA256, вычисляемый по канонической перекодировке JSON-тела: значения с плавающей точкой, представляющие целые числа, сокращаются до целых чисел, ключи рекурсивно сортируются, используются компактные разделители, Unicode сохраняется.
→ Полная документация по webhook, включая X-Signature по исходным байтам, устаревший X-Signature-Simple с подписью только конверта и рекомендации по выбору варианта. Didit повторяет неудачные доставки (5xx, 404, тайм-аут) до 2 раз (через ~1 мин, затем через ~4 мин) и прерывает ожидание через 5 секунд, поэтому возвращайте 2xx быстро.

Через API (необязательно)

Получить тот же payload решения можно в любой момент:
Структура ответа (массивы во множественном числе) совпадает с объектом decision в payload webhook, а endpoint можно вызвать на любом этапе жизненного цикла сессии. Используйте webhook для обновлений в реальном времени, а вызовы API оставьте для догрузки данных, аудита и восстановления: endpoint /decision/ ограничен 600 GET-запросами в минуту на один API-ключ (см. Ограничение частоты запросов). Семантика ошибок: неизвестный session_id возвращает 404 с {"detail": "Not found."}; ошибки аутентификации возвращаются как 403, этот endpoint никогда не возвращает 401. Ссылки на медиафайлы в ответе — это предварительно подписанные ссылки с коротким сроком действия, поэтому загружайте их сразу и не сохраняйте. → Справочник API для получения сессии

Полные примеры кода

Node.js / Express

Python / FastAPI


Статусы сессии

Ниже перечислены 10 возможных значений status. Это точные строки с учетом регистра (обратите внимание: Kyc Expired записывается с одной заглавной буквой K): Полный жизненный цикл, переходы между статусами и диаграмму Mermaid см. в разделе Статусы верификации.

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

  1. Выберите способ интеграции:
  2. Настройте webhook: Webhook
  3. Спланируйте необходимые мощности: Ограничение частоты запросов
  4. Обработайте каждый статус: Статусы верификации
  5. Настройте сценарий: Сценарии
  6. Проверьте доступность API: Проверка состояния

Нужна помощь?

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