Developers
Authentication
Sign in with a session cookie, complete MFA when required, check the session and sign out.
ReferenceContent reviewed
On this page
Password login establishes a session using an HttpOnly auth_token cookie. A successful login response does not contain an accessToken field. With MFA enabled, login returns a pending challenge before a full session is issued.
Sign in#
Send POST /api/auth/login with these JSON fields:
| Field | Type | Required |
|---|---|---|
email | string | Yes |
password | string | Yes |
timezone | string | No |
Without MFA, success returns message and user and sets the cookie. With MFA, it returns mfa_required: true and mfa_pending_token. HTTP 200 alone does not establish that MFA is complete.
These are alternative clients. Keep the same cookie store throughout the flow.
For curl, set MANTRAWORX_URL to your HTTPS host without a trailing slash. Prepare a private login.json with your own email and password using the fields above, and set COOKIE_JAR to a private writable file. Keep both files out of source control and shared logs. Remove the password file when no longer needed.
Run this function on the MantraWorx origin, supplying credentials from your form.
For Python, install requests, set MANTRAWORX_URL and retain this session for later calls.
Complete MFA#
Send POST /api/mfa/challenge with mfa_pending_token and one of these fields:
| Field | Meaning |
|---|---|
token | Current authenticator code. |
backup_code | An unused backup code. |
email_otp | An email code requested for this challenge. |
Request an email code through POST /api/mfa/email-otp/send with mfa_pending_token, then send the received code to the challenge endpoint. Follow the server's resend delay.
A successful challenge returns user and sets the full session cookie. The pending token is single-use. Restart login if it expires or has already been redeemed.
Verify and use the session#
Call GET /api/auth/me and check the intended account. Reuse the login cookie store.
For same-origin browser calls, use credentials: "same-origin". Cross-origin use also requires an allowed origin and compatible cookie settings; credentials: "include" alone does not bypass browser restrictions.
The server can accept an Authorization: Bearer credential in supported contexts. This does not mean password login issues a bearer credential in its response body.
Sign out#
Send POST /api/auth/logout with the session cookie. It revokes the presented session credentials and clears the cookie. Stop using the local cookie store after logout.
Diagnose a failed login#
| Condition | Next action |
|---|---|
| 401 / invalid credentials | Check your email and password or use recovery. |
| Account inactive or access ended | Ask your administrator about account eligibility. |
| 429 | Respect the retry delay; repeated attempts do not unlock the account. |
| Invalid MFA code | Use the current code or another available recovery method. Restart login for an expired challenge. |
| 503 | Retry later; authentication verification is temporarily unavailable. |
The endpoint defaults to 20 failed attempts per 15 minutes for the same address and email. Separate account and MFA protections also apply. Follow the actual response rather than assuming a fixed waiting period.
Password endpoints#
| Endpoint | Purpose |
|---|---|
POST /api/auth/forgot-password | Request a reset email. |
POST /api/auth/reset-password | Finish a reset with the emailed token. |
POST /api/auth/setup-password | Complete invitation password setup. |
POST /api/auth/change-password | Change the signed-in account's password. |
For user-facing steps, read Signing in and access.
Need more help?
Can’t find what you need? Talk to the team.
To report a problem with this guide, include its title and the step that blocked you.