Crypto-as-a-Service integration

A CaaS integration is assembled from the same documented API surface used across WhiteBIT’s B2B products. It does not restate the schemas — each linked guide carries the endpoint and field detail.

​

Prerequisites

• A CaaS engagement scoped with WhiteBIT — see the CaaS overview for what the model delivers and the path to launch.
• Architecture alignment — the instance, branding, and asset scope agreed during onboarding (see Architecture alignment during onboarding).
• API access — HMAC-signed requests; each capability’s endpoint and field detail lives in the linked product guide.

​

Integration building blocks

​

Core API access

• REST and WebSocket. 100+ authenticated REST endpoints and 14 public endpoints, plus WebSocket market data and private account streams. Requests are signed with HMAC-SHA512 using the X-TXC-APIKEY, X-TXC-PAYLOAD, and X-TXC-SIGNATURE headers. See First API Call. Order placement, modification, and cancellation over the same connection arrive September 2, 2026 (global platform only), authorized once on the connection rather than per request.
• SDKs and tooling. Official Go, Python, and PHP SDKs, plus an MCP server and a CLI for AI-assisted integration. See SDKs and AI tools.
• API keys. Two-factor authentication is required before key creation; the secret is shown only once at creation; up to 50 trusted IPs can be whitelisted per key; keys auto-deactivate after 14 days of inactivity and are revoked on an account password change, block, or freeze. See Authentication.
• Rate limits. Limits are set per scope and per endpoint. See Rate limits for current values rather than assuming a single figure.

​

Wallets and payments

• Deposit addresses. Generate a unique address per end user with POST /api/v4/main-account/create-new-address; incoming funds are reconciled by webhook. See the Payment Integration guide and the Wallet-as-a-Service developer guide.
• Withdrawals. Fee-inclusive (/withdraw) and fee-on-top (/withdraw-pay) variants, plus withdrawal after conversion using the Convert service — request a quote, confirm at the quoted rate, then withdraw in the destination currency. See Payment Integration and Convert.
• Fiat rails (EUR/SEPA). Available after Phase 2 onboarding — API-generated deposit invoices and SEPA withdrawals. See the On/Off-Ramp guide.
• WhiteBIT Codes. Fee-free internal crypto transfers between WhiteBIT accounts, useful for settlement flows. See WhiteBIT Codes.
• Crypto Lending. Fixed and Flex lending endpoints are restricted to B2B partners and require access to be granted through the institutional services form. See Crypto Lending.

Travel Rule affects deposits and withdrawals for EEA and Turkey accounts — the primary CaaS segments (banks, EMIs, fintechs). The Travel Rule API for programmatic verification is enabled per account via institutional@whitebit.com; see Regulatory Compliance. For transfers in scope of the Travel Rule, originator and beneficiary information is required. See Travel Rule for the field requirements and the transfer flow.

​

Account architecture

• Sub-accounts. Create and manage thousands of separate accounts under one umbrella, each with independent balances, API keys, and IP whitelists, with fee-free instant transfers between the main account and its sub-accounts. See Sub-Accounts.
• Fast API Key via OAuth. For flows where end users hold personal WhiteBIT accounts, a partner can issue user-scoped API keys through the OAuth API key flow. New partner integrations use this flow. See Fast API Key via OAuth and the OAuth overview.
• Trading and conversion. Spot markets across 800+ pairs, and the Convert service for instant conversion at a quoted rate without placing orders on the order book. See Convert.

​

Architecture alignment during onboarding

The public documentation covers the API surface, but not the full dedicated-instance model behind CaaS. The items below define the integration architecture and are agreed and documented with WhiteBIT during onboarding, before development starts.

• Instance model — how the dedicated, custom-branded instance relates to the public API surface, and which base URL and credentials the environment uses.
• End-user account mapping — how end customers map onto the WhiteBIT account model (for example, one sub-account per end user, versus a pooled account with the partner’s own internal ledger), and the reconciliation and limit trade-offs of each.
• KYC and KYB split — which party verifies end customers, at which levels, and how verification status is exchanged between the partner and WhiteBIT.
• Data residency and privacy — where end-customer data is processed and stored, and the Data Processing Agreement (available via compliance@whitebit.com).
• Operational roles — which staff hold which permissions (API key scopes, sub-account administration, withdrawal approval).
• Support model — support tiers, response targets, and incident channels beyond the public status page.
• Fee and settlement terms.

​

Operating the integration

• Webhooks. Real-time notifications for deposits, withdrawals, code redemptions, and refunds, verified with an HMAC-SHA512 signature. Pair webhooks with periodic history polling as a reconciliation fallback. See Webhooks.
• Monitoring. status.whitebit.com reports platform, API, and blog status; whitebit.com/system-page reports per-asset deposit, withdrawal, and transfer availability.
• Testing. WhiteBIT does not offer a public testnet. Test on the live API with minimum order sizes and low-minimum assets; Demo Tokens are available for risk-free spot practice.
• Go-live. Work through the Go-Live Checklist — covering authentication, error handling, rate limits, compliance, WebSocket, webhooks, monitoring, and testing.

​

Support

• Primary contact: the assigned account manager, plus the support channels agreed during onboarding.
• Programs and onboarding: institutional@whitebit.com.
• Compliance, VASP, and DPA: compliance@whitebit.com.
• Self-service: help.whitebit.com for platform questions; docs.whitebit.com for API documentation.

​

What’s next