Managani Docs

Appearance

Authentication ​

MANAGANI supports multiple authentication methods.

Bearer Token (JWT) ​

Obtain a JWT by logging in:

bash
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:

bash
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:

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

Access tokens do not expire and are ideal for integrations.

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

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.