Authentication

Fangate uses Laravel Sanctum personal access tokens for authenticated API access.

Most creator-facing endpoints require:

Authorization: Bearer {token}
Accept: application/json

Auth model

• POST /api/register creates the creator account and immediately returns a bearer token.
• POST /api/login returns a new bearer token for an existing account.
• POST /api/login/batch authenticates up to 10 creators in one request and returns a token per successful row (for account-switcher clients).
• POST /api/logout revokes the current token.
• Public endpoints such as registration, login, password reset, report submission, and app bootstrap do not require a token.

App session listing and revocation for the current user use GET /api/user/sessions and DELETE /api/user/sessions/{tokenId} (Sanctum tokens named api only). See Auth API reference.

Registration flow

The current backend registration flow is:

1. The client sends the confirmation mail with POST /api/user/email/verify; the creator opens the link in it. That click confirms the address - GET /api/registration/email-status tells whether it happened. Registration is refused without it (errors_code: email_not_confirmed).
2. The creator signs the contract in the embedded signature form; GET /api/registration/signature-status tells when the signature has arrived.
3. The user completes registration with POST /api/register (with registration_legal_accepted: true).
4. The backend creates the user, applies referral / master-account rules, provisions the payout currency, and returns a Sanctum token.

The whole flow is described step by step in Onboarding, including how to run it from a registration screen of your own.

Important validation rules:

• email must be unique and pass Fangate's trusted-email validation.
• password is required and must satisfy Laravel's password validation.
• birth_date must make the user at least 18 years old.
• currency_id is the payout currency and permanent once the account exists; send it (ids from GET /api/app-data). If omitted, the backend derives it from the affiliate / default currency setup.

Example:

curl -X POST https://fangate.info/api/register \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{"email":"creator@example.com","password":"SecurePass123!","first_name":"Casey","last_name":"Creator","birth_date":"1998-04-12","currency_id":1,"registration_legal_accepted":true}'

The address must have been confirmed (the click on the mail from POST /api/user/email/verify) and the contract signed before this call succeeds - see Onboarding.

Login flow

POST /api/login accepts email and password and returns:

{
  "success": true,
  "errors_message": null,
  "data": {
    "user": {
      "id": 123,
      "email": "creator@example.com"
    },
    "token": "1|sanctum-token-value"
  }
}

Notes:

• Fangate currently uses token auth, not cookie session auth, for public API integrations.
• The same user may have multiple active tokens across devices until logout/revocation.

Multi-account switching

There is no separate “switch session” endpoint: each successful login returns a bearer token. The client stores tokens for each creator it manages and sends Authorization: Bearer {chosen token} for API calls. Combined dashboard KPIs across several creators are available via POST /api/dashboard/summary/aggregate (documented under Wallet).

Email verification flow

POST /api/user/email/verify is public and is used before or during registration depending on the client.

The backend stores contextual fields such as app-link and request-source data so mobile and web flows can redirect correctly after the email action.

Environment-specific behavior:

• verification links target the app and API the request came from

See Environments.

Password reset

POST /api/user/password/reset is public.

Important behavior:

• the endpoint intentionally returns a success-style response even when the email is not found
• clients should not use the response to infer whether an account exists

Logout

POST /api/logout requires authentication.

Current backend behavior:

• revokes the current bearer token
• optionally removes a device FCM token when the request includes fcm_token

Authenticated user lookup

GET /api/user returns the current authenticated creator resource.

This is the canonical endpoint for:

• profile bootstrap after login
• verification state
• payout/bank details
• default adult-content settings
• feature flags exposed in the user resource

See Users.

Authorization rules

The API is authenticated at the token level, but authorization is also enforced per resource.

Common examples:

• a creator can only update their own user/profile data
• a creator can only manage their own products and media
• consent-tag responses are only available to the tagged user
• wallet and affiliate endpoints are scoped to the authenticated creator

Typical failures:

• 401 Unauthorized for missing or invalid token
• 403 Forbidden when the token is valid but the resource is not owned by the caller

See Error Handling.