Перейти к основному содержанию
Серверные SDK являются официальными библиотеками Didit для вашего бэкенда. Каждый из них вызывает серверные endpoint справочника API с типизированными запросами и ответами, проверяет webhook, которые Didit отправляет вам, и проверяет токены Didit Authentication. Ни один релиз 1.0.1 пока не содержит два endpoint’а Google Wallet: запуск верификации Google Wallet и отправка ответа кошелька. В SDK для Python, Node.js, Java, PHP, Ruby и .NET есть все остальные серверные endpoint. В Go 1.0.1 также нет ещё девяти endpoint’ов, в основном endpoint’ов Travel Rule: см. Endpoint’ов, которых пока нет в SDK для Go. Используйте их везде, где ваш код хранит API-ключ Didit: создание сессий верификации, чтение решений, вызов отдельных API, управление пользователями, компаниями, сценариями и кейсами, скрининг транзакций и кошельков, а также Travel Rule. В браузере или мобильном приложении вместо них используйте веб- и нативные SDK: они показывают пользователю процесс верификации и никогда не хранят ваш API-ключ. Страницы серверных endpoint справочника API, в том числе страницы службы Проверка по базам данных, показывают пример кода для каждого серверного SDK рядом с запросом cURL. Пример выводится, когда последний релиз SDK содержит endpoint и каждое поле, которое отправляет пример. Endpoint или поле, добавленные в API, получат примеры с очередным релизом каждого SDK. Ни один релиз 1.0.1 не содержит 16 полей запроса Проверки по базам данных, добавленных после генерации SDK, например vin или bank_account_number, поэтому страницы служб, которые их отправляют, показывают только cURL.

​
Установка

​
Настройка

Все SDK читают одни и те же переменные окружения, поэтому клиент, созданный без параметров, готов к работе. В edge-средах нет окружения процесса: там передайте API-ключ клиенту Node.js как параметр. Всё, что можно задать через окружение, можно также передать клиенту, а также базовый URL, таймаут, повторные попытки, заголовки по умолчанию и собственный HTTP-клиент. Создайте один клиент на процесс и используйте его совместно: он поддерживает пул соединений и безопасен для использования из нескольких потоков или задач. Методы account (программная регистрация: регистрация, вход, организации и приложения) обращаются к https://apx.didit.me/auth/v2 и никогда не отправляют ваш API-ключ. Выполните вход через account.login, затем передайте полученный токен доступа клиенту как токен аккаунта.

​
Что делает каждый SDK

  • Ресурсы и методы. Вызовы следуют ресурсам API: client.<resource>.<method>(...), например sessions.create, sessions.retrieve_decision или transactions.create, с написанием, принятым в каждом языке. Идентификаторы пути передаются позиционными аргументами; тело и параметры запроса составляют один набор именованных полей. Python, Node.js, PHP и Ruby используют имена полей API (workflow_id); Go, Java и .NET используют регистр своего языка (WorkflowID, workflowId, WorkflowId).
  • Списки. Методы списков автоматически перебирают все результаты (limit и offset под капотом), а также предоставляют каждую страницу с полями count, next, previous и results. В Ruby auto_paging_each проходит все страницы, а total_count, next_url и previous_url страницы соответствуют count, next и previous API.
  • Файлы. Загрузки (изображения документов, селфи, подтверждение адреса, импорты) принимают путь, байты или поток. Загрузки с сервера (PDF сессий, отчёты) возвращают байты или поток, а не разобранный JSON.
  • Совместимость вперёд. Поле ответа или значение перечисления, которые версия SDK ещё не знает, сохраняются и доступны для чтения, но не вызывают ошибку, поэтому добавление в API не ломает работающую интеграцию.
  • Webhook. webhooks.verify проверяет заголовки X-Signature-V2 и X-Signature и метку времени доставки с помощью вашего секрета webhook и возвращает типизированное событие. Во время ротации секрета он принимает список секретов. Схему подписи см. в разделе Webhook.
  • Аутентификация. Помощник Authentication проверяет токены доступа и ID-токены, которые подписывает ваш издатель сервиса Authentication, и вызывает его endpoint токенов, сессий и повышения уровня аутентификации. Он никогда не использует ваш API-ключ.

​
Ошибки, повторные попытки и таймауты

Все ошибки наследуются от DiditError. В Go каждая ошибка реализует интерфейс didit.Error и является типом-указателем, например *didit.NotFoundError. В Java, PHP и .NET ошибки называются привычным для языка образом с суффиксом Exception, а API пишется как Api: DiditException, ApiStatusException, NotFoundException. SDK повторяют неудачный запрос до 2 раз с экспоненциальной задержкой, начиная с 0,5 секунды (полный джиттер, не более 8 секунд), и учитывают заголовок Retry-After. Запросы GET, HEAD, PUT и DELETE повторяются при ошибках соединения, таймаутах, а также при ответах 408, 429 и 5xx. Запросы POST и PATCH повторяются только при ответе 429 или если соединение не удалось установить до отправки запроса, поэтому повторная попытка никогда не создаст вторую сессию или вторую транзакцию. Таймаут по умолчанию составляет 60 секунд. Каждый ответ также предоставляет необработанный HTTP-статус, заголовки и идентификатор запроса. Лимиты, стоящие за ответом 429, описаны в разделе Ограничение частоты запросов.

​
Версионирование и поддержка

  • SDK следуют семантическому версионированию с одним правилом для изменений API. Изменение, которое отражает API Didit, выпускается как минорная версия, даже если оно может сломать типизированный код (поле, у которого изменился тип, поле, которое теперь может быть null, или удалённый endpoint, поле или значение перечисления). API уже ведёт себя так для всех вызывающих сторон, поэтому более старая версия SDK не безопаснее. В примечаниях к выпуску такие изменения перечислены в разделе «Изменения API, которые могут сломать типизированный код».
  • Мажорная версия выпускается только для изменения самого дизайна SDK: переименования или удаления метода или ресурса, которые API при этом сохраняет, изменения конфигурации клиента, поведения ошибок, повторных попыток, пагинации или проверки webhook, а также отказа от поддержки версии среды выполнения. Когда endpoint уходит из API или метод переименовывается, старый метод сохраняется как минимум ещё на одну минорную версию и помечается как устаревший, чтобы ваш код продолжал собираться, пока вы переходите на новый. Каждый язык ведёт собственную нумерацию версий: Node.js, PHP и Ruby имеют версию 2.x, а остальные имеют версию 1.x, поскольку эти три SDK выпустили изменение API как мажорную версию до того, как появилось это правило.
  • SDK генерируются из опубликованного контракта API (openapi-25.json и openapi-auth.json), а их методы Didit Authentication проверяются по openapi-authentication.json. Все семь SDK проверяют все три контракта ежедневно, поэтому новый endpoint или поле попадает в очередной релиз всех семи SDK.
  • Каждый SDK поддерживает минимальную версию среды выполнения из таблицы и все более новые версии. Его тесты запускаются на минимальной версии и на каждой более новой, а для Node.js и Java на каждом релизе с долгосрочной поддержкой.
  • Файл CHANGELOG.md в каждом репозитории содержит изменения каждого релиза.
  • Сообщать о проблеме безопасности нужно приватно: через security advisories в репозитории SDK или на support@didit.me.
Последнее изменение 7 ноября 2026 г.