Authentication
Two ways to call /api: browser session or Application credentials.
Last updated 2026-09-01
What it is
Most Business routes accept either a valid user session or valid Business Application credentials. The middleware prefers the session cookie when present, otherwise Application headers.
| Mode | Credential | Typical client |
|---|---|---|
| Session | httpOnly cookie _i_s | Web app browser |
| Application | X-Client-Id + X-Client-Secret | Server / automation |
Session auth
After POST /api/auth/login, the API sets _i_s. Include credentials (cookies) on subsequent requests. Logout clears the session. Sensitive account changes may require re-authentication endpoints under /api/auth/reAuth.
User auth endpoints (selection)
- POST /api/auth/register
- POST /api/auth/login
- POST /api/auth/logout
- POST /api/auth/forgot-password / verify/reset / reset
- POST /api/auth/verify/email and resend routes
Application auth
Send both headers on every Integration request:
X-Client-Id— public client identifierX-Client-Secret— secret from create/rotate
Credentials are Business-scoped. Access is limited to granted scopes. Revoked Applications fail with unauthorized.
Who can access
Session users must be active with a valid, non-expired session. Applications must be active and not revoked, with a verifiable secret.
Constraints
- No OAuth/SSO for users or Integrations
- Do not put client secrets in frontend bundles
- Platform admin uses a separate Bearer JWT scheme — not for Business Integrations