Вход в аккаунт
Люди входят на platform.invoise.me через почту или Google. После настройки выдайте бэкенду API-ключ магазина.
Агент, которому нужна сессия аккаунта, использует вход по кошельку. Он только для агентов: в интерфейсе его нет, а запрос из браузера отклоняется. Для приёма платежей не нужно реализовывать все методы входа ниже.
Почта и Google
Заголовок раздела «Почта и Google»Эти маршруты обслуживают интерфейс. Все пути начинаются с /api/v1:
| Запрос | Назначение |
|---|---|
POST /auth/email/start |
запрашивает код с телом {"email":"[email protected]"} и возвращает challenge_id. |
POST /auth/email/verify |
обменивает challenge_id и code на сессию. |
GET /auth/google |
начинает переход через браузер. /auth/google/callback принимает ответ провайдера. |
Ответ сессии содержит token, expires_at, csrf и user. Перед продолжением проверьте user.mfa_required и user.onboarding_required.
Адрес на домене одноразовой почты отклоняется с 400 disposable_email, если для него ещё нет аккаунта, в том числе при привязке email к аккаунту. Существующие аккаунты входят как прежде.
MFA и безопасность
Заголовок раздела «MFA и безопасность»Управлять вторыми факторами удобнее в интерфейсе. Эти маршруты требуют сессии:
| Запрос | Назначение |
|---|---|
POST /auth/totp/enroll |
начинает подключение и возвращает URI настройки. |
POST /auth/totp/verify |
принимает code; "enroll":true нужно только для подтверждения подключения. |
POST /auth/recovery |
принимает код восстановления вместе с основной сессией. |
POST /auth/passkeys/begin |
Начать регистрацию или проверку passkey. |
POST /auth/passkeys/finish/{id} |
Завершить регистрацию или проверку passkey. |
PATCH /auth/passkeys/{id} |
Переименовать passkey. |
DELETE /auth/passkeys/{id} |
Удалить passkey. |
POST /auth/confirm |
проверяет достаточность свежей авторизации, но сам по себе не подтверждает MFA. |
POST /auth/logout |
отзывает сессию. |
Сессии кошелька подчиняются настроенному MFA. API-ключ не может подключать, удалять или обходить факторы аккаунта.
Cookie браузера и bearer-токен
Заголовок раздела «Cookie браузера и bearer-токен»Интерфейс использует cookie сессии. Запросам на изменение с cookie нужны корректные Origin и X-CSRF-Token. Серверная интеграция передаёт bearer-токен, поэтому cookie-проверка CSRF ей не нужна.
Держите секреты на сервере. Методы работы с аккаунтом и командой — в справочнике API.