Authentication

MANAGANI supports multiple authentication methods.

Bearer Token (JWT)

Obtain a JWT by logging in:

curl -X POST https://app.managani.com/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com", "password": "your-password"}'

Use the returned token in subsequent requests:

curl https://app.managani.com/api/v1/sites \
  -H "Authorization: Bearer <jwt_token>"

JWT tokens expire after 7 days.

Access Token (Personal Token)

Generate a personal access token in Settings > Access Tokens within the app. Use it as:

curl https://app.managani.com/api/v1/sites \
  -H "Authorization: Token <access_token>"

Access tokens do not expire and are ideal for integrations.

Requests with rejected credentials are counted per network address. Too many rejected requests return 429 until the rate-limit window ends.

PUT /api/v1/profile cannot change the email address with a bearer token, personal access token, or OAuth token. It returns 403 with the code email_change_requires_session. Change the address from Settings > Profile in the web app.

OAuth Integrations

Authorization codes can be exchanged once and must include the matching client, redirect URI, and PKCE verifier. Start a new authorization flow if a code has already been used or has expired.

Each successful refresh replaces the refresh token. Store the replacement before making another refresh request, and serialize refresh requests from the same client session. An old or already used refresh token returns invalid_grant; reconnect the client if it no longer has a valid replacement.

/oauth/register accepts 60 requests and /oauth/token accepts 600 requests per network address in 15 minutes. More requests return 429.

Client metadata and remote signing-key documents must use HTTPS and resolve to public network addresses. Loopback and private-network destinations are rejected, including hostnames that resolve to those addresses.

Additional Auth Methods

The web interface also supports:

• Magic Links — passwordless login via email (15-min expiry, prefetch-safe two-step confirm)
• Passkeys — WebAuthn-based biometric/hardware key authentication
• 2FA (TOTP) — Time-based one-time passwords via authenticator apps. Password and magic-link sign-ins both ask for the code when 2FA is on.

Magic Link Security Flow

Magic links are intentionally a two-step browser flow to prevent email-client preview/prefetch requests from consuming one-time tokens:

1. GET /magic?token=... only renders a confirmation page.
2. POST /magic is the only endpoint that redeems the token and creates a session.

This means link scanners that issue automatic GET requests cannot burn a login token before the user confirms.

Choose and Protect Your Credential

Use the authentication method documented for the endpoint you are calling. A personal access token is convenient for server-side integrations because it can be managed from the account settings. A browser session or a specialized signed token may be required for routes that are not ordinary REST resource operations.

Keep credentials in server-side configuration rather than browser code, public repositories, screenshots, or support messages. When investigating a failed request, record the endpoint and response status while removing the authorization header from logs shared with other people.

Check that the credential belongs to the intended account and has access to the requested resource. If a previously working integration loses access, review token revocation and account membership before changing the request body. Rotate a credential when it has been exposed, then update the integration to use the replacement. Revoking an unused token is preferable to leaving an unmaintained integration authorized indefinitely.

Live site-update events omit widget signing secrets and connected-service access tokens. Keep those credentials on the server that uses them.