Account sign-in

People sign in at platform.invoise.me with email or Google. After setup, give your backend a shop API key.

Agents that need an account session use wallet sign-in. It is for agents only: the dashboard does not offer it, and a browser request to it is refused. Receiving payments does not require implementing every sign-in method below.

Email and Google

These routes back the dashboard. All paths use /api/v1:

Request	Purpose
POST /auth/email/start	requests a sign-in code with {"email":"[email protected]"} and returns challenge_id.
POST /auth/email/verify	exchanges challenge_id and code for a session.
GET /auth/google	starts the browser redirect. /auth/google/callback handles the provider callback.

Session responses contain token, expires_at, csrf and user. Check user.mfa_required and user.onboarding_required before proceeding.

An address on a disposable email domain is refused with 400 disposable_email when it has no account yet, including when you link an email to an account. Accounts that already exist keep signing in.

MFA and account security

Use the dashboard to manage second factors. These routes require a login session:

Request	Purpose
POST /auth/totp/enroll	starts enrollment and returns a setup URI.
POST /auth/totp/verify	accepts code; add "enroll":true only when confirming enrollment.
POST /auth/recovery	accepts a recovery code with an existing primary session.
POST /auth/passkeys/begin	Start passkey registration or verification.
POST /auth/passkeys/finish/{id}	Complete passkey registration or verification.
PATCH /auth/passkeys/{id}	Rename a passkey.
DELETE /auth/passkeys/{id}	Remove a passkey.
POST /auth/confirm	checks whether the session meets the fresh-auth requirement. It does not satisfy MFA by itself.
POST /auth/logout	revokes the session.

Wallet sessions are subject to the same configured MFA. An API key cannot enroll, remove or bypass account factors.

Browser cookies or bearer tokens

The dashboard uses a session cookie. Cookie-authenticated writes require the matching Origin and X-CSRF-Token headers. Server integrations send a bearer token and do not need cookie-based CSRF handling.

Keep credentials server-side. For account and team operations, see the API reference.