Обзор
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 и использовать их напрямую.
Базовый URL
Все endpoint этого руководства находятся на хосте аутентификации:https://verification.didit.me/v3). Хост аутентификации выдаёт JWT-токены доступа и управляет приложениями. Хост верификации обрабатывает сессии, AML, сценарии и т. д., и аутентификация на нём выполняется с помощью долгоживущего api_key, который вы получаете в этом процессе.
Быстрый старт
Шаг 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: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 выглядит так:
Управление приложениями
После аутентификации вы можете получать, создавать и обновлять приложения в своей организации. Это идеальный вариант для реселлеров, которые хотят иметь отдельное приложение для каждого клиента. У каждого приложения есть собственные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 mcp add --transport http didit https://mcp.didit.me/mcp. Клиенты, которые работают только через stdio (Windsurf, Zed), подключаются через мост mcp-remote, который выполняет для вас процесс OAuth.
API-ключ, который вы получаете в процессе регистрации выше, предназначен для вызова REST API с вашего бэкенда. MCP его никогда не использует. Подробности см. в обзоре MCP и в инструкциях по установке для каждого клиента.
Справочник по форматам ошибок
Все endpointapx.didit.me/auth/v2 используют одни и те же три формата ответов (см. openapi-auth.json):
- Валидация на уровне полей:
{"field": ["message", ...]}с HTTP400. - Валидация на уровне формы (в первую очередь сложность пароля и ошибки кода подтверждения): простой массив
["Invalid or expired verification code."]без дополнительной оболочки с HTTP400. - Аутентификация и бизнес-правила:
{"detail": "..."}с кодами400,401,403,404или429. Ответы429содержат заголовокRetry-After, который сообщает, сколько нужно ждать перед повторной попыткой (тело содержит толькоdetail).
{"detail": "..."}, а в ответах 429 есть заголовки X-RateLimit-* и Retry-After. См. Ограничение частоты запросов.