Authentication

Many endpoints in this API are public. Some data endpoints require a paid plan and a platform-issued API key. A small set of endpoints either accept a Binance API key/secret pair in the request body, or look up a key the user has previously registered with the platform via email.

There are five patterns. Each endpoint page identifies which pattern it uses.

1. Public endpoints

No authentication header. This covers the core crypto market-data endpoints and the strategy CRUD endpoints. Public endpoints are still subject to per-IP rate limiting (see General Info).

1b. Plan-gated endpoints (platform API key)

Certain data endpoints require a paid subscription and are gated by plan tier. Currently the stock, index, and commodity K-line (klines) endpoints require at least the Standard plan (标准套餐).

After purchasing a plan, the platform issues a data API key (prefixed pk_) tied to your account — distinct from any Binance trading key. Pass it on every request to a plan-gated endpoint via the X-Primit-API-Key header:

X-Primit-API-Key: pk_xxxxxxxxxxxxxxxx

The backend validates the key and confirms the subscription is active. Responses:

HTTP	Cause
401	Missing or invalid X-Primit-API-Key.
403	The plan required by the endpoint is not active (subscription expired or never purchased).

You can find and manage your data API key on the dashboard after subscribing.

2. Body-supplied credentials (*/auth and a few POST endpoints)

A subset of endpoints — primarily the ones that submit live orders or fetch account-scoped data on behalf of a caller — accept the caller's Binance API credentials directly in the JSON request body.

The shared body shape:

{
  "api_key": "<binance-api-key>",
  "api_secret": "<binance-api-secret>",
  "...endpoint-specific fields..."
}

These credentials are used to sign the upstream Binance request and are not persisted. Endpoints in this category include the variants suffixed with /auth (e.g. /orders/auth, /orders/cancel/auth, /positions/close/auth, /leverage/auth, /margin-type/auth) and a handful of other POST endpoints that take an ApiCredentials body. The trading-side endpoints themselves are out of scope for this documentation site.

3. Email-based registered key lookup

Used by callers who previously uploaded a Binance API key to the platform and want the platform to use that stored key.

Verify a registered key

POST /api-key/verify

Request body:

{ "email": "user@example.com" }

Response:

{
  "success": true,
  "message": "API 密钥验证成功",
  "email": "user@example.com",
  "has_api_key": true
}

Get registered key status

GET /api-key/status/{email}

Response (no key registered):

{
  "success": false,
  "message": "用户不存在或没有API密钥",
  "email": "user@example.com",
  "has_api_key": false
}

Response (key registered):

{
  "success": true,
  "message": "获取状态成功",
  "email": "user@example.com",
  "has_api_key": true,
  "verification_status": "verified",
  "last_verified": "2026-04-29T12:00:00",
  "created_at": "2026-04-01T00:00:00",
  "is_active": true
}

4. Google sign-in (Bearer app token)

Native apps sign the user in with Google and exchange the result for a platform app token — a scoped JWT used as a Bearer credential on user-scoped endpoints.

Exchange a Google ID token

POST /auth/mobile/google

The app obtains a Google ID token from the Google Sign-In SDK and posts it. No X-Backend-Key is required.

Request body:

{ "id_token": "<google-id-token>" }

The backend verifies the token via Google (RS256 signature, expiry, issuer accounts.google.com, audience, and email_verified), then creates or links the user by google_id / email.

Response — 200 OK:

{
  "access_token": "<app-jwt>",
  "user": {
    "id": 123,
    "email": "user@example.com",
    "name": "Jane Doe",
    "google_id": "1067290000000000000",
    "apple_id": null,
    "is_vip": false,
    "vip_expires_at": null,
    "created_at": "2026-06-01T00:00:00",
    "updated_at": "2026-06-24T00:00:00"
  }
}

HTTP	Cause
401	Invalid or expired id_token, or email not verified.
503	Google verification dependency unavailable.

Using the app token

Send the returned access_token as a Bearer header on user-scoped endpoints:

Authorization: Bearer <app-jwt>

The token is an HS256 JWT scoped to the user and expires per server configuration. Apple sign-in works the same way via the parallel POST /auth/mobile/apple endpoint (body { "identity_token": "<apple-identity-token>" }).

What is not used

The platform does not sign requests with HMAC. Apart from the plan-gated data API key (X-Primit-API-Key, see pattern 1b) and the Bearer app token issued by Google / Apple sign-in (above), it does not require any other X-Primit-* headers.