Broker Integration Guide

Complete guide for the WhiteBIT Broker Program — fee share model, customer onboarding, sub-account management, per-customer API keys, and revenue monitoring.

The WhiteBIT Broker Program enables trading platforms and fintechs to offer WhiteBIT exchange infrastructure to end users. Brokers earn a share of trading fees generated by referred users. The guide covers program enrollment, customer onboarding, sub-account architecture, API key management, and revenue tracking.

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 increases the fee share percentage:

WBT Holdings	Fee Share
200 WBT	40%
Up to 2,000,000 WBT	50%

Check the Broker Program page for the current WBT tier table with all intermediate breakpoints.

How to apply: Contact [e-mail] with the business description and expected user volume.

Program benefits:

• Sub-account architecture for per-customer isolation
• Per-customer API keys
• Fee-free internal transfers between master and sub-accounts
• Cross-marketing support

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/create — API 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-url — API 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.

curl

# 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"
  }'

Python

import hashlib
import hmac
import json
import time
import base64
import requests

API_KEY = "YOUR_API_KEY"
API_SECRET = "YOUR_SECRET"
BASE_URL = "https://whitebit.com"

def send_request(endpoint, payload):
    payload["request"] = endpoint
    payload["nonce"] = str(int(time.time() * 1000))
    body = json.dumps(payload)
    encoded = base64.b64encode(body.encode()).decode()
    signature = hmac.new(
        API_SECRET.encode(), encoded.encode(), hashlib.sha512
    ).hexdigest()
    headers = {
        "Content-Type": "application/json",
        "X-TXC-APIKEY": API_KEY,
        "X-TXC-PAYLOAD": encoded,
        "X-TXC-SIGNATURE": signature,
    }
    return requests.post(f"{BASE_URL}{endpoint}", headers=headers, data=body)

# Create a sub-account
response = send_request("/api/v4/sub-account/create", {
    "alias": "customer-001",
})
sub_account = response.json()
print(sub_account)

# Generate a KYC URL
response = send_request("/api/v4/sub-account/kyc-url", {
    "id": sub_account.get("id"),
})
print(response.json())

For Go and PHP examples, see SDKs.

Sub-account management

Sub-accounts provide complete isolation — each customer has independent balances, order history, and API credentials.

CRUD operations:

Operation	Endpoint	Description
Create	POST /api/v4/sub-account/create	Create a new sub-account
List	POST /api/v4/sub-account/list	List all sub-accounts
Block	POST /api/v4/sub-account/block	Suspend trading for a customer
Unblock	POST /api/v4/sub-account/unblock	Re-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 per sub-account and monitor across all sub-accounts for aggregate reporting.

See the Sub-Accounts Overview for the complete product overview.

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

Track fee share revenue across all referred users to monitor Broker Program earnings.

Fee share tracking: Monitor trading activity across sub-accounts to estimate fee share earnings. The worked fee share calculation from the Overview section applies to each trade executed by a referred user.

Reporting recommendations:

• Track trading volume per sub-account over 30-day rolling windows
• Monitor fee tier progression — higher volume improves the base fee rate, which increases the absolute fee share
• Export trade history per sub-account for reconciliation

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 [e-mail] to begin the process.

Integration checklist

Complete the following checklist before going live with the Broker Program integration.

• Program enrollment — Application submitted to [e-mail] 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

Full product overview for the sub-account system.

Institutional Onboarding

Step-by-step KYB and fiat onboarding process.

Go-Live Checklist

Pre-production readiness verification.