Access Management

Two steps get you ready to trade:

Authentication: sign in with an API key, a wallet, or email, and learn how requests are scoped. OAuth 2.0 covers the delegated flow, where a user grants your app access to their own account.
Trade Accounts: connect an exchange account (Hyperliquid, Binance, Bybit, OKX, or Lighter) and pass its id on every trading call. Connect an Exchange walks through what each venue needs first, from deposit to approvals.

A third is optional: Account Linking attaches more ways to sign in to the same Pear account, and puts a trader on the leaderboard through X.

Every account-scoped call therefore carries two headers:

curl "https://pro-gateway.pearprotocol.io/positions" \
  -H "x-api-key: $PEAR_API_KEY" \
  -H "x-trade-account-id: $TRADE_ACCOUNT_ID"

The first says who you are, the second says which exchange account to act on.

x-trade-account-id is required on the routes that need it, with no default: one connected account is treated the same as ten. Trading and account reads — positions, trade, fills, portfolio, executions, fee, ladders, leverage, rebalance, saved baskets, schedules, fill and funding sync, TCA, triggers — return 400 without it. Account-level routes do not take it at all: trade-accounts, api-keys, users, notifications, referrals, and the Lighter gateway.

Reference	Endpoints
Authentication	Nonce, login, session refresh, email verification, account links.
API Keys	Create, list, and revoke keys.
Trade Accounts	Connect, update, restore, delete, and read credentials for venue accounts.
OAuth Grants	Review and revoke what a user granted a client.
Users	Read the profile, set the display name and preferences.

The OAuth 2.0 protocol endpoints — discovery, client registration, authorize, token, and revoke — are not in the generated reference. They are documented on the OAuth 2.0 page, and the discovery document is the source to read them from at runtime.