​
Authentication Methods

The project has three access methods at the same time: API Key authentication, native-compatible authentication headers, and browser login session state. First, distinguish whether you are accessing a relay route or a /api/* admin route.

​
Bearer Token

Used for most relay routes, including:
  • /v1/*
  • /v1beta/*
  • /mj/*
  • /suno/*
  • /kling/v1/*
  • /dashboard/billing/*
Request header: 
Authorization: Bearer YOUR_API_KEY

​
Claude Native-Compatible Headers

Used for POST /v1/messages and other pages in Claude native format: 
x-api-key: YOUR_API_KEY
anthropic-version: 2023-06-01

​
Gemini Native-Compatible Headers

Used for GET /v1beta/models and POST /v1beta/models/{model}:{action}: 
x-goog-api-key: YOUR_API_KEY
It also supports the query parameter style ?key=YOUR_API_KEY.

​
User Login Session State

Used for /api/user/*, backend management, and some frontend dashboard APIs. Typical characteristics:
  • Authentication is controlled by middlewares such as UserAuth, AdminAuth, and RootAuth.
  • On failure, many APIs still return HTTP 200, but success is false.

​
OAuth Browser Flow

​
1. Generate state

GET /api/oauth/state
Successful response: 
{
  "success": true,
  "message": "",
  "data": "a1b2c3d4e5f6"
}

​
2. Redirect to the standard OAuth provider

GET /api/oauth/{provider}
This route is used by browser callbacks. The server will validate state, fetch user information, bind or create an account, and then establish a login session state. Common provider values are determined by the OAuth configurations actually enabled, for example:
  • github
  • discord
  • oidc
  • linuxdo

​
Common Responses on Authentication Failure

​
Relay Routes

{
  "error": {
    "message": "Invalid API key provided",
    "type": "invalid_request_error",
    "param": "",
    "code": "invalid_api_key"
  }
}

​
/api/* Routes

{
  "success": false,
  "message": "Invalid token"
}