Вхід в обліковий запис

Люди входять на platform.invoise.me через email або Google. Після налаштування видайте своєму бекенду API-ключ магазину.

Агенти, яким потрібна сесія облікового запису, використовують вхід через гаманець. Він призначений лише для агентів: кабінет його не пропонує, а запит із браузера до нього відхиляється. Прийом платежів не вимагає реалізації всіх способів входу нижче.

Email і 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 і безпека облікового запису

Використовуйте кабінет для керування другими факторами. Ці маршрути вимагають сесії входу:

Запит	Призначення
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-ключ не може підключати, видаляти чи обходити фактори облікового запису.

Кукі браузера чи bearer-токени

Кабінет використовує кукі сесії. Записи з автентифікацією через кукі вимагають відповідних заголовків Origin і X-CSRF-Token. Серверні інтеграції надсилають bearer-токен і не потребують обробки CSRF на основі кукі.

Тримайте облікові дані на сервері. Про операції з обліковим записом і командою див. у довіднику API.