Skip to main content
For developers. This page covers the technical integration. For what WaaS is, the models at a business level, and how to apply, see the WaaS overview.
The integration models are described in the Integration models concept. This guide covers where to start for each and the flows the models share.

​
Prerequisites

  • Approved WaaS partner enrollment — see the WaaS overview for what WaaS provides and how to apply.
  • A chosen backend model — managed sub-accounts, attribution, or KYC reliance; compare on the integration models concept.
  • API access — HMAC-signed requests; per-user deposit addresses (create-new-address) enabled for the account.

​
Where to start per model

  • Managed sub-accounts. WhiteBIT creates a dedicated sub-account per end user under the partner’s master account and performs KYC on each one. Build with Sub-Accounts for account creation and management, and the Embedded Trading integration guide for the full walkthrough — eligibility, per-customer API keys, and fee-share reconciliation.
  • Attribution (own account + OAuth). Each end user keeps a personal WhiteBIT account and grants the partner a scoped API key through the consent screen. Build against Fast API Key via OAuth for the authorization flow, key issuance, and permission scopes.
  • Sub-accounts with KYC reliance. The same sub-account architecture as the managed model, but the partner performs end-user KYC instead of WhiteBIT, under a Compliance-approved agreement. Build with the same Embedded Trading integration guide; complete Institutional Onboarding first to establish the reliance agreement. See KYC reliance eligibility below for the conditions.
Commercial terms for the program: 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.

​
KYC reliance eligibility

KYC reliance — WhiteBIT relying on the partner’s own customer verification — may be available, but is not enabled by default. It is never automatic, and operates as a delegation: responsibility for customer verification is never transferred. Eligibility is assessed case by case. Reliance is available only to partners that are supervised AML-obligated entities (for example EMI, PI, VASP, or MiCA-CASP license holders) in an adequate jurisdiction, applying broadly equivalent customer due diligence, under a written agreement and an individual WhiteBIT Compliance assessment. A confirmed entry on the relevant public register establishes the licensing basis; a confirmed EU/MiCA entity is additionally required when EU users are in scope. Licensing regimes and entity structures vary, and the examples above may not capture every case. Describe your licence(s), jurisdiction, and customer due-diligence approach in full in your application so the WhiteBIT Compliance team can review your specific situation and make a determination.

​
Payment and payout flows

Fund-movement flows, with parameters and code examples, are in the Payment Integration guide. The per-user deposit and payout cycle: Reconcile by webhook, and poll transaction history as a required fallback: webhook delivery is retried but has no replay, so an event can be missed and must be recovered by polling. Deduplicate by uniqueId. See Webhooks for signatures and delivery semantics. API rate limits apply per endpoint; sub-account limits are set per agreement.
Fiat deposit and withdrawal operate at the master-account level (institutional fiat access). Per-end-user fiat rails are not a standard shipped capability; confirm any such requirement with WhiteBIT first.
Compliance requirements that affect the requests:
  • EEA withdrawals require a travelRule object; in the sub-account models the partner submits it for each sub-account withdrawal it initiates. Inbound EEA/Turkey deposits are held until verification completes. See Travel Rule.
  • For EEA users, use USDC or EURI, not USDT. See Regulatory Compliance.

​
More flows

Additional use cases (conversion payouts, refunds, exact-amount payouts, multichain payouts) are catalogued in Recipes, with the full parameter reference in the Payment Integration guide. Travel Rule (programmatic): submit originator data via travel-rule/deposit/verification and fetch the VASP list via travel-rule/vasps (EEA and Turkey). See Travel Rule.

​
Testing

WhiteBIT does not offer a public testnet or sandbox. Test on the live API with minimum amounts, and check per-asset minimums via the Asset Status endpoint first. The WhiteBIT Codes flow is a low-risk way to try a real signed call on a small amount (see Recipes).

​
What’s next

WaaS Recipes

Runnable examples and the starter repo.

Payment Integration

Endpoint-level reference for every payment and payout flow.

FAQ

Scope, integration models, onboarding, and compliance questions.