Шаг 1: Получение учётных данных
Есть два способа получитьapi_key:
Вариант A: программная регистрация (без браузера)
Лучше всего подходит для CI/CD и ИИ-агентов. Два вызова API,POST /programmatic/register/ и затем POST /programmatic/verify-email/, возвращают api_key прямо в ответе.
→ Полный процесс, правила пароля, срок действия JWT и политику блокировки см. в разделе Программная регистрация.
Вариант B: в консоли Didit
- Перейдите в Didit Console.
- Создайте организацию или выберите существующую.
- Перейдите в Settings → API & Webhooks.
- Скопируйте:
- API Key: используется как заголовок
x-api-keyв каждом вызове верификации. - Webhook Secret Key: используется для проверки HMAC-подписей webhook.
- API Key: используется как заголовок
Переменные окружения
Шаг 2: Создание сценария
Перед созданием сессий нужен сценарий верификации. Сценарии определяют, через какие шаги верификации проходят пользователи.Создание в консоли
- Перейдите в Didit Console → Workflows
- Нажмите Create Workflow
- Выберите базовый шаблон:
- Добавьте необязательные функции:
- Скопируйте 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.
Вариант C: перенаправление
Перенаправьте пользователя на URL верификации.Вариант D: мобильный WebView
Для мобильных приложений без нативного SDK.Шаг 5: Получение результатов
Через webhook (рекомендуется)
Webhook уведомляет ваш сервер в реальном времени при изменении статуса верификации. Настройка:- Создайте адрес назначения webhook в Консоли (API и вебхуки) или через
POST /v3/webhook/destinations/сwebhook_version: "v3"и массивомsubscribed_events(например,["status.updated"]) - Сохраните
secret_shared_key, который возвращается при создании: это секрет HMAC для всех вариантов подписи - Реализуйте на своем сервере endpoint 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 сохраняется.
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 см. в разделе Статусы верификации.
Следующие шаги
- Выберите способ интеграции:
- Мобильные приложения → Нативные SDK
- Веб-приложения → Веб-SDK
- Настройте webhook: Webhook
- Спланируйте необходимые мощности: Ограничение частоты запросов
- Обработайте каждый статус: Статусы верификации
- Настройте сценарий: Сценарии
- Проверьте доступность API: Проверка состояния
Нужна помощь?
- Поддержка: support@didit.me
- Программный онбординг: Программная регистрация