Skip to main content
For developers. This page covers the technical integration. For what YaaS is, the model, and how to apply, see the Yield-as-a-Service overview.
Yield-as-a-Service uses Model A — one sub-account per end user, with the Crypto Lending lifecycle run inside each sub-account using that sub-account’s own API key. This guide covers the B2B layer — provisioning, funding, and per-user reconciliation. The lending lifecycle itself is documented in the Crypto Lending quickstart; the only difference here is the signing key.

​
Prerequisites

  • Crypto Lending enabled where it runs. Lending is available on the master account with B2B access; on sub-accounts it is not enabled by default — request enablement for each end-user sub-account via the account manager or institutional@whitebit.com (see the overview). Until it is enabled, the lending endpoints are not available on that sub-account.
  • A sub-account per end user, each with its own type:2 API key (info, trading, deposits, withdraws) — type:2 is required to run lending on a sub-account.
  • Funds in the master Main balance to allocate to each sub-account.
  • HMAC-signed requests — see Authentication.

​
Integration building blocks

​
1. Provision a sub-account per end user

Create one sub-account per end user and issue that sub-account a type:2 API key. Build with Sub-Accounts for account creation and key management, and the Embedded Trading integration guide for the full walkthrough (per-customer keys, KYC-URL branding).

​
2. Fund the sub-account

Move funds from the master Main balance to the end user’s sub-account with a fee-free transfer.

​
3. Offer yield inside the sub-account

Run the Crypto Lending lifecycle — fetch plans, invest, track, withdraw — signed with the sub-account’s own key, so investments and interest stay in that sub-account’s balance. The request and response fields are documented in the Crypto Lending quickstart; the only B2B difference is the signing key.
The main-account/ path segment addresses the signing account’s own Main balance — for a sub-account key, that is the sub-account’s balance, not the master’s. This is why a sub-account key runs the lending lifecycle against that end user’s funds.

​
4. Reconcile earnings per user

Each sub-account’s investments and payment history are that end user’s earnings. There is no aggregated cross-sub report, so attribution is per sub-account — read each sub-account with its own key. Per-user lifecycle:

​
Testing

WhiteBIT does not offer a public testnet or sandbox. Test on the live API with minimum amounts, and check available plans and per-plan minimums via the plans endpoints first.

​
Reference

​
What’s next

FAQ

How B2B yield differs from the self-service flow.

Crypto Lending

Plan mechanics, supported assets, and the endpoint reference.

Sub-Accounts

Create and manage the per-user accounts this program provisions.