Skip to main content

Authentication

Most endpoints in this API are public. 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 three patterns. Each endpoint page identifies which pattern it uses.

1. Public endpoints​

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

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": "[email protected]" }

Response:

{
  "success": true,
  "message": "API 密钥验证成功",
  "email": "[email protected]",
  "has_api_key": true
}

Get registered key status​

GET /api-key/status/{email}

Response (no key registered):

{
  "success": false,
  "message": "用户不存在或没有API密钥",
  "email": "[email protected]",
  "has_api_key": false
}

Response (key registered):

{
  "success": true,
  "message": "获取状态成功",
  "email": "[email protected]",
  "has_api_key": true,
  "verification_status": "verified",
  "last_verified": "2026-04-29T12:00:00",
  "created_at": "2026-04-01T00:00:00",
  "is_active": true
}

What is not used​

The platform does not sign requests with HMAC, does not require any X-PipAI-* headers, and does not issue platform-scoped API keys at this time.