Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt

Use this file to discover all available pages before exploring further.

The WhiteBIT Broker Program enables trading platforms and fintechs to offer WhiteBIT exchange access to end users. Brokers earn up to 40% of trading fees generated by referred customers. Each customer trades from a dedicated sub-account under the broker’s master account, with fee-free internal transfers and per-customer API keys.

Broker Program overview

The Broker Program offers a revenue-sharing model where brokers receive up to 40% of trading fees generated by referred users. Fee share model: The base fee share is 40% of the trading fee generated by each referred user. Worked example:
Referred user trades $10,000 on BTC_USDT (spot)
Standard trading fee: 0.1% taker = $10.00
Broker fee share (40%): $10.00 × 0.40 = $4.00
WBT holding boost tiers: WBT is WhiteBIT’s native utility token (WhiteBIT Token). Holding WBT in the broker’s master account boosts the fee share percentage above the 40% base:
WBT HoldingsFee Share
200 WBT40%
4,000 WBT42%
10,000 WBT44%
30,000 WBT46%
100,000 WBT48%
2,000,000 WBT50%
The 200 WBT entry matches the no-WBT 40% base; the first uplift starts at 4,000 WBT. The canonical tier table is published on the Broker Program page. How to apply: Contact institutional@whitebit.com with the business description and expected user volume. Program benefits:
  • Per-customer sub-accounts: each end customer trades from a dedicated sub-account with its own balance, order history, and API credentials
  • Per-customer API keys
  • Fee-free internal transfers between master and sub-accounts
  • Joint marketing activities: social media co-posts, blog posts, targeted email newsletters, AMA sessions, and trading competitions, scheduled with WhiteBIT during onboarding

Customer onboarding flow

Each end customer is onboarded as a sub-account under the broker’s master account.
1

Create a sub-account

Call the sub-account creation endpoint to create a new sub-account for the customer. Each sub-account receives an independent balance and can have dedicated API keys.Endpoint: POST /api/v4/sub-account/createAPI Reference
2

Generate a KYC verification URL

Generate a KYC URL for the sub-account holder. The end customer completes KYC verification through the WhiteBIT interface (WhiteBIT-branded, not white-label).Endpoint: POST /api/v4/sub-account/kyc-urlAPI Reference
3

Customer completes KYC

The end customer opens the KYC URL and completes identity verification. The broker monitors KYC status via the sub-account details endpoint.
4

Enable trading

Once KYC is approved, transfer initial funds to the sub-account (fee-free) and create an API key for the sub-account if the customer needs direct API access.
The KYC verification flow is WhiteBIT-branded. The broker cannot white-label the KYC interface.
# Create a sub-account
curl -X POST "https://whitebit.com/api/v4/sub-account/create" \
  -H "Content-Type: application/json" \
  -H "X-TXC-APIKEY: YOUR_API_KEY" \
  -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
  -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
  -d '{
    "alias": "customer-001",
    "request": "/api/v4/sub-account/create",
    "nonce": "YOUR_NONCE"
  }'

# Generate a KYC URL for the sub-account
curl -X POST "https://whitebit.com/api/v4/sub-account/kyc-url" \
  -H "Content-Type: application/json" \
  -H "X-TXC-APIKEY: YOUR_API_KEY" \
  -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
  -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
  -d '{
    "id": "SUB_ACCOUNT_ID",
    "request": "/api/v4/sub-account/kyc-url",
    "nonce": "YOUR_NONCE"
  }'
For Go and PHP examples, see SDKs.

Sub-account management

Each sub-account holds an independent balance (scoped to spot, collateral, or both at creation), order history, and API credential set with its own IP whitelist and permission scope. Trades on one sub-account do not affect another. Withdrawal approval remains under the broker’s master account. CRUD operations:
OperationEndpointDescription
CreatePOST /api/v4/sub-account/createCreate a new sub-account
ListPOST /api/v4/sub-account/listList all sub-accounts
BlockPOST /api/v4/sub-account/blockSuspend trading for a customer
UnblockPOST /api/v4/sub-account/unblockRe-enable trading for a customer
Fee-free transfers: Transfer funds between the master account and any sub-account without fees using POST /api/v4/sub-account/transfer — see the API Reference.
  • Master to sub-account: funding a customer account
  • Sub-account to master: revenue collection
Balance monitoring: Query balances across all sub-accounts in a single call via POST /api/v4/sub-account/balances — see the API Reference. For per-sub-account balance queries scoped to a single customer, call the balance endpoint using the sub-account’s own API key. See the Sub-Accounts Overview for the full sub-account product reference.

Per-customer API keys

Each sub-account can have dedicated API keys with independent IP whitelists and permissions.
  • Create API keys per sub-account for customers who need direct API access
  • IP whitelisting: up to 50 IP addresses per API key
  • Permissions: configure per-key permissions (Info + Trading vs. Info + Trading + Deposit + Withdraw)
Create separate API keys for each customer sub-account. Do not share the master account’s API keys with customers.
See Security Best Practices for API key management guidance. For structured order tracking across customer sub-accounts, use clientOrderId naming conventions — see Client Order ID: Broker Implementation.

Revenue monitoring

The Broker Program does not currently expose a dedicated fee-share endpoint. Earnings are reported through the WhiteBIT Analytical Dashboard, which tracks referral statistics, trading volumes, WBT Holding tier, and VIP level in real time. Fee-share payouts are credited to the broker’s main account on a monthly cadence. Programmatic reconciliation:
  1. List sub-accounts via POST /api/v4/sub-account/list.
  2. For each sub-account, query trade history via POST /api/v4/trade-account/executed-history using the sub-account’s own API key — see the API Reference.
  3. For each executed deal, multiply the fee charged by the broker’s active fee-share percentage from the WBT tier table.
  4. Sum across all sub-accounts to produce the broker’s earnings for the reporting window.
Reporting recommendations:
  • Reconcile against the dashboard monthly so dashboard-credited payouts match locally computed totals.
  • Track each referred user’s trading volume separately — a single high-volume customer can change the master account’s effective fee tier and lift the absolute fee share without any new customers being added.
  • Export per-sub-account trade history into a ledger column matching the monthly settlement statement.

Fiat for broker end users

European broker end users frequently expect EUR deposit and withdrawal capabilities. Fiat operations (EUR/SEPA) require institutional onboarding with fiat access approval. The broker’s master account must complete the two-phase onboarding process (crypto access via KYB, then fiat access via fiat processing partner review). Once fiat access is approved on the master account, sub-accounts can process fiat deposits and withdrawals. See Institutional Onboarding for the two-phase process. See Payment Integration for fiat endpoint details.
Fiat deposit and withdrawal access requires completion of institutional onboarding including the fiat provider approval phase. Contact institutional@whitebit.com to begin the process.

Integration checklist

Complete the following checklist before going live with the Broker Program integration.
  • Program enrollment — Application submitted to institutional@whitebit.com and approved.
  • Master account KYB — KYB verification completed for the broker entity.
  • API key generated — Master account API key created with appropriate permissions.
  • Sub-account creation — Successfully created at least one test sub-account.
  • KYC URL generation — KYC URL generated and tested for a sub-account.
  • Fund transfer — Fee-free transfer between master and sub-account verified.
  • Per-customer API key — API key created for a sub-account with IP whitelist configured.
  • Balance monitoring — Sub-account balance query working.
  • Fee share tracking — Revenue monitoring process established.
  • Fiat access (if applicable) — Institutional onboarding Phase 2 completed for SEPA access.
  • Security review — IP whitelists, API key permissions, and secret storage reviewed per Security Best Practices.
  • Go-live review — All items on the Go-Live Checklist verified.

What’s Next

Sub-Accounts

Sub-account isolation model, transfer mechanics, and per-key permission scopes.

Institutional Onboarding

Step-by-step KYB and fiat onboarding process.

Go-Live Checklist

Pre-production readiness verification.