Authentication

Bearer tokens

Add the session token to each private request with the Authorizationheader. The token represents one majjha account and carries that account's permissions.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

First-party app sign-in

The majjha app uses Dynamic for account sign-in. After the user completes that flow, the app exchanges the verified provider session for the same majjha Bearer token accepted by private REST and WebSocket endpoints. This exchange is handled by the first-party client; integrations should not attempt to recreate its provider flow.

Email and password (local development)

Locally created accounts can exchange credentials for a session at POST /api/auth/login. This compatibility flow is useful while developing against a local stack.

curl -X POST "https://api.majjha.fun/api/auth/login" -H "Content-Type: application/json" -d '{ "email": "[email protected]", "password": "••••••••" }'

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…",
  "user": {
    "id": "usr_123",
    "email": "[email protected]",
    "name": "Ada",
    "username": "ada",
    "role": "USER"
  }
}

Verify a session and read the current account with GET /api/auth/me:

curl "https://api.majjha.fun/api/auth/me" -H "Authorization: Bearer $MAJJ_TOKEN"

Keep sessions safe

• Treat majjha and Dynamic session tokens like passwords; never commit them.
• Store server-side credentials in environment variables, not source control.
• Do not expose a private session token in a public browser bundle or client log.
• Use the smallest permission scope available for automated integrations.

Authentication errors

A missing or invalid token returns 401 Unauthorized. A valid token without the required role returns 403 Forbidden. See Errors for the response format.