Access and refresh tokens are signed with different secrets. Their payload includes user ID, email, active organization ID, and token type. The gateway does not trust the role from the token: authentication reloads the accepted membership and derives the current organization role.
Send name and email to /auth/initiate-signup. The gateway rate-limits the request and sends an email-verification challenge.
2
Verify the code
Send email, six-character code, and type: email_verification to /auth/verify-otp when the UI flow requires explicit verification.
3
Complete signup
Send email, organizationName, a password of at least eight characters, and optional domain to /auth/complete-signup.
Send email and password to /auth/login. The response includes access/refresh tokens and organization context. When a user belongs to multiple tenants, use organization switching before tenant-scoped operations.
Verify /memberships/verify-invite/:token, then accept through /memberships/accept-invite with the values required by the invitation response/UI.
Store refresh tokens in a secure, non-script-readable location where your application architecture permits. Rotate tokens after refresh if the response provides a replacement and discard them on logout.
The widget exchanges public configuration/visitor context for a short-lived token whose JWT type is widget_session. Widget middleware rejects operator tokens and scopes the resulting connection.
AI service
Internal tool endpoints use x-ai-tool-secret. The header is only for trusted service-to-service calls on a private network.
Provider webhooks
Email, Twilio, Telegram, and billing callbacks use provider-specific verification and rate limits rather than operator JWTs.
Replace the example JWT and internal secrets before deployment. Never expose access tokens in URLs; although authentication contains a query-token compatibility path, URLs are commonly logged by proxies and browsers.
.png?fit=max&auto=format&n=2PCWzKfmo53nDkKR&q=85&s=9f6b13dc0c2829ec8db5437603939f93)