Partner Solutions

WhiteBIT partners integrate through program funnels — one per partner type. Pick a partner type from the cards, or use the three structural questions to route an overlapping label. Each path leads to a program overview, an integration guide, and a program FAQ. Partner programs are approval-gated — see How to apply.

​

Choose an integration path

Partner labels overlap (a single business can span two different architectures), so the fastest routing comes from three structural questions:

1. Account holding — the account structure follows from what the partner expects for each end user. Compare the models on the integration models concept.
   • Do end users sign in to personal WhiteBIT accounts, with the partner acting through a partner-held API key? → Model B → App Builders.
   • Should WhiteBIT keep a separate balance for each end user, with separate API keys? → a partner-operated sub-account per end user, Model A → Embedded Trading for trading, Wallet-as-a-Service for wallet products.
   • Does the partner keep each end user’s balance in the partner’s own ledger, with one WhiteBIT account and a deposit address per end user? → Crypto-as-a-Service.
2. Direction — is the partner building on the WhiteBIT API, or proposing WhiteBIT integrate into an external platform or network? The latter is a partnership conversation — contact institutional@whitebit.com directly (see Funds & Institutions).
3. Scope — trading, payments, or both? Payment and payout integrations route to Payments & Fiat regardless of the answers above. Exception: a crypto offering that a partner runs for its own end users under its own brand, from its own WhiteBIT account with a deposit address per end user, routes to Crypto-as-a-Service.
   • Crypto-as-a-Service or On/Off-Ramp? Do end users keep a crypto balance with the partner after a purchase? Yes → Crypto-as-a-Service: an address per end user and balances in the partner’s ledger; fiat is added through the on/off-ramp routes. No, the partner only converts between fiat and crypto → On/Off-Ramp.

Common use cases mapped to a program:

​

REST vs. WebSocket decision matrix

Order placement runs over REST for request–response confirmation and atomic bulk placement; the WebSocket order methods add an alternative on the same authorized connection, on the global platform only. Combining REST for order management with WebSocket for market data remains the most common integration pattern. See the WebSocket API for the available channels and the API Reference for endpoint details.

​

How to apply

Partner-program applications go to institutional@whitebit.com and are individually reviewed before provisioning. Including the following in the first message routes the application to the right team without extra clarification rounds: About the company (all applicants):

1. Registered legal entity — full legal name, registration number, and jurisdiction (not a brand or product name).
2. Licenses or registrations held, with the regulator and register reference. Licensing is assessed in the individual review; KYC reliance follows the eligibility conditions.
3. Application capacity — the applicant’s own behalf or on behalf of a client — and the intended contracting counterparty.

About the integration (all applicants):

4. Direction — building on the WhiteBIT API, or proposing WhiteBIT integrate into an external platform or network (the latter is a partnership conversation rather than an application).
5. Intended account structure: (a) own main account only, including a deposit address per end user with the partner’s own end-user ledger; (b) end users’ own WhiteBIT accounts with a partner-held API key; (c) per-customer sub-accounts under the partner’s main account; (d) another structure, or not sure — describe what the partner expects for each end user (see the account-holding question under Choose an integration path), and WhiteBIT proposes the closest supported model.
6. Scope — crypto only, or fiat as well, and at which level (partner account or end users).

About end users (partners serving end users):

7. The party performing end-user KYC — the partner or WhiteBIT — and, for partner-side KYC, the supervisory basis.
8. The user population reached — direct clients, or customers of the partner’s merchants or clients — and the business vertical.
9. The countries where the service is offered or marketed, and the geo-gating approach (how the service restricts availability by user country or region).
10. For sub-account requests: settlement topology — per-customer deposit addresses, or deposits and withdrawals concentrated at the main account with internal allocation.

​

Program terms and security

Program terms — revenue share and eligibility — differ by program; the specific band and how the share is reported are on each program overview. Security certifications apply platform-wide. Revenue-share terms depend on the program. Embedded Trading partners earn a share of the trading fees that referred customers generate across all products, with payouts initiated by the partner, most commonly once per month — see WhiteBIT Embedded Trading for current rates. Other partner programs confirm commercial terms during onboarding.

​

What’s next