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

Обзор

Didit — самая удобная для AI-агентов платформа верификации личности. AI-агенты для программирования (Cursor, Claude Code, GitHub Copilot, Devin, OpenHands, Codex) могут зарегистрироваться, настроить сценарии и начать верификацию личности, и всё это программно, без открытия браузера. Почему агентам нравится Didit:
  • 2 вызова API от нуля до учётных данных (регистрация и verify-email).
  • Браузер не нужен: всё работает в фоновом режиме, что идеально подходит для CI/CD и сценариев с агентами.
  • Второй фактор не требуется для нового API-аккаунта: токены возвращаются сразу после подтверждения email.
  • Автоматически созданные организация и приложение с api_key в ответе на верификацию.
  • Полный API для управления: сценарии, анкеты, списки, биллинг — всё через API.
  • Доступен MCP-сервер: агенты могут находить инструменты Didit и использовать их напрямую.
Полная спецификация опубликована в openapi-auth.json; endpoint ниже проверены по ней.

Базовый URL

Все endpoint этого руководства находятся на хосте аутентификации:
Это отдельный хост, отличный от хоста API верификации (https://verification.didit.me/v3). Хост аутентификации выдаёт JWT-токены доступа и управляет приложениями. Хост верификации обрабатывает сессии, AML, сценарии и т. д., и аутентификация на нём выполняется с помощью долгоживущего api_key, который вы получаете в этом процессе.

Быстрый старт

Используйте настоящий адрес электронной почты, на который можно получать письма. Endpoint отправляет код подтверждения синхронно, поэтому почтовый сервис отклоняет письма на адреса в зарезервированных тестовых доменах (@example.com, @example.org, @*.test, @*.example, @*.invalid), и вызов возвращает 500. Замените плейсхолдер you@yourdomain.com ниже на почтовый ящик, к которому у вас есть доступ.

Шаг 1: Регистрация

Ответ (201 Created):
Шестисимвольный буквенно-цифровой код подтверждения (например, A3K9F2) отправляется на адрес электронной почты. Код истекает через 10 минут после отправки. Если срок истёк, снова вызовите этот endpoint с тем же email и паролем: для ещё не подтверждённого аккаунта он вернёт 200 с текстом "A new verification code has been sent to your email." и новым кодом. Отдельный endpoint POST /programmatic/resend-otp/ (тело запроса: {"email", "password"}) также повторно отправляет код, между отправками действует ограничение 60 секунд. Оба маршрута используют общий лимит запросов на регистрацию, описанный ниже.

Шаг 2: Подтверждение кода и получение учётных данных

Ответ (200 OK):
Теперь у вас есть всё необходимое. Сохраните application.api_key в безопасном месте и передавайте его в заголовке x-api-key в каждом вызове API верификации.
Токены — это JWT, подписанные RS256. Значение expires_in по умолчанию равно 86400 секундам (24 часа). Токен доступа нужен только для endpoint управления на apx.didit.me/auth/v2. Трафик API верификации на verification.didit.me/v3 аутентифицируется долгоживущим api_key, а не JWT.

Шаг 3: Использование API

Последующие входы

При последующих входах с любого устройства обменяйте email и пароль на новый JWT:
Endpoint сразу возвращает access_token и refresh_token, браузер не нужен. Затем вызовите GET /organizations/me/, чтобы узнать свой org_id (uuid организации), после чего GET /organizations/me/{org_id}/applications/, чтобы получить список приложений организации (uuid каждой записи является app_id), и наконец GET /organizations/me/{org_id}/applications/{app_id}/, чтобы получить api_key.
Учётные записи, созданные в консоли с email и паролем, также могут использовать POST /programmatic/login/ после подтверждения email. Для учётных записей консоли, использующих только OAuth, перед использованием этого входа без браузера необходимо задать пароль.

Что делать, если для входа требуется что-то ещё

POST /programmatic/login/ возвращает токены только тогда, когда у аккаунта нет второго фактора. Возможны ещё три варианта ответа, и агент, автоматизирующий вход, должен обрабатывать каждый из них: Для автоматизации используйте API-ключ, так как он не требует входа. Аккаунт с вторым фактором не может завершить вход через этот endpoint.

Требования к паролю

Проверяются на стороне сервера, по одному правилу за раз: первая ошибка прерывает проверку и возвращает ошибку в виде простого массива, например ["Password must contain at least one uppercase letter."]. (Другие ошибки валидации на этом endpoint используют оболочку с ключом поля {"password": [...]}. Формат простого массива для правил сложности пароля — известная несогласованность на стороне сервера. В клиентском коде обрабатывайте его как {"password": [...]}.)

Лимиты запросов и блокировки

Три независимых механизма защищают хост аутентификации. Любой из них может вызвать ответ 429. Заголовок ответа Retry-After сообщает, сколько нужно ждать перед повторной попыткой. Тело ответа 429 выглядит так:
Лимиты Verification API (например, 600 сессий в минуту) независимы от этих и описаны в разделе Ограничение частоты запросов.

Управление приложениями

После аутентификации вы можете получать, создавать и обновлять приложения в своей организации. Это идеальный вариант для реселлеров, которые хотят иметь отдельное приложение для каждого клиента. У каждого приложения есть собственные client_id, api_key, метаданные и настройки. Это также полезно, если в вашей организации есть разные продукты, бренды, регионы, среды или сценарии использования, которые нужно держать раздельно.
Для просмотра списка, создания или обновления приложений пользователь должен быть владельцем или администратором целевой организации. В противном случае возвращается ответ 403.

Что могут делать агенты после регистрации

С помощью api_key агенты получают полный доступ к Verification API. Аудированные пути на https://verification.didit.me/v3: Полный перечень см. в справочнике Management API.

Интеграция с MCP-сервером

Для наилучшей работы агентов используйте размещённый MCP-сервер Didit по адресу https://mcp.didit.me/mcp. API-ключ не требуется: при первом подключении клиент откроет браузер, вы нажмёте Войти через Didit (OAuth 2.1 с PKCE), и сервер будет действовать от вашего имени с правами вашей роли в консоли. Клиенты с нативной поддержкой удалённых MCP-серверов (Cursor, VS Code) используют эту запись. Claude в вебе и Desktop добавляют её как пользовательский коннектор:
Claude Code: claude mcp add --transport http didit https://mcp.didit.me/mcp. Клиенты, которые работают только через stdio (Windsurf, Zed), подключаются через мост mcp-remote, который выполняет для вас процесс OAuth. API-ключ, который вы получаете в процессе регистрации выше, предназначен для вызова REST API с вашего бэкенда. MCP его никогда не использует. Подробности см. в обзоре MCP и в инструкциях по установке для каждого клиента.

Справочник по форматам ошибок

Все endpoint apx.didit.me/auth/v2 используют одни и те же три формата ответов (см. openapi-auth.json):
  • Валидация на уровне полей: {"field": ["message", ...]} с HTTP 400.
  • Валидация на уровне формы (в первую очередь сложность пароля и ошибки кода подтверждения): простой массив ["Invalid or expired verification code."] без дополнительной оболочки с HTTP 400.
  • Аутентификация и бизнес-правила: {"detail": "..."} с кодами 400, 401, 403, 404 или 429. Ответы 429 содержат заголовок Retry-After, который сообщает, сколько нужно ждать перед повторной попыткой (тело содержит только detail).
Хост верификации возвращает ошибки в виде {"detail": "..."}, а в ответах 429 есть заголовки X-RateLimit-* и Retry-After. См. Ограничение частоты запросов.
Последнее изменение 7 ноября 2026 г.