Read time … min

AI-native runtime for WhiteBIT trading strategies

Author in Cursor, Claude Code or any AI IDE. Deploy from GitHub into a managed cloud runtime with first-class MCP control, logs and region selection.

By the TradingHost engineering team

Section 01 · At a glance

At a glance

Venue
WhiteBIT
Venue type
Crypto exchange (global)
Asset class
Crypto
Supported products
Spot, perpetual futures, isolated margin. Tiered per-endpoint rate limits; no public testnet (integration testing happens on live API with minimum order sizes).
Runtime model
Containerised strategy runtime
Deployment source
GitHub
Languages
Any language that runs in a container
Common integrations
Native WhiteBIT REST and WebSocket APIs, CCXT, custom connectors
AI workflow integration
MCP control surface for Cursor, Claude Code, GitHub Copilot and CLI agents
TradingHost role
Runtime, deployment, logs, health checks, region selection, MCP control
WhiteBIT role
Exchange account, API access, market access, execution venue
Affiliation
TradingHost is independent and is not affiliated with WhiteBIT

Section 02 · What WhiteBIT offers

What WhiteBIT offers

WhiteBIT offers spot, perpetual futures and isolated margin via REST and WebSocket APIs with tiered per-endpoint rate limits. Notable operational reality: there is no public testnet, so integration testing happens against the live API with minimum order sizes. Copy trading, auto-invest and staking are platform-only and have no API access. Endpoint specifics change over time. The shape is durable; precise rate limits, symbol lists and fee tiers live in WhiteBIT’s docs.

Markets and strategy patterns

  • Spot trading on USDT, BTC and ETH-quote pairs
  • Perpetual futures strategies
  • Isolated margin strategies
  • WebSocket subscription up to 200 messages per minute per connection
  • Tiered per-endpoint rate-limit budgeting
  • Live-API integration testing (no public testnet available)
  • Balance-transfer flow between trade and main accounts
  • API-driven strategies that avoid platform-only features (copy trade, auto-invest)

API surface

Product surfaces
Spot, perpetual futures and isolated margin. Copy trading, auto-invest and staking exist on WhiteBIT but are platform-only (no API access). Strategies that depend on those features need a human-in-the-loop step.
Connection methods
REST API for order placement and account queries with tiered per-endpoint rate limits: Main Balance 1,000 requests per 10 seconds, Trade Balance 12,000 per 10 seconds, Order create 10,000 per 10 seconds, public markets 2,000 per 10 seconds. WebSocket allows up to 1,000 concurrent connections per minute with 200 messages per minute per single connection.
Authentication
API key and secret per strategy with HMAC-signed requests. Permissions can be scoped per key. WebSocket subscriptions to private channels require a token-refresh flow that the client must handle.

For specifics, refer to WhiteBIT

Specific endpoints, rate-limit weights, symbol lists, fee tiers and version history live in WhiteBIT’s documentation. Treat these as the source of truth.

Section 03 · Build with AI

Build your WhiteBIT strategy with AI

Pick an integration method, fork a TradingHost framework starter, and author your strategy in an AI IDE. Cursor, Claude Code, GitHub Copilot and CLI-based AI agents all work with the same GitHub-native deployment loop.

  • Native WhiteBIT API

    Direct control over WhiteBIT-specific behaviour, balance-transfer flows and tiered rate limits.

  • CCXT

    Common interface across WhiteBIT and other crypto exchanges. CCXT exposes WhiteBIT through the unified `whitebit` class for spot trading.

    Get started with CCXT

  • Freqtrade or Hummingbot

    Neither framework lists WhiteBIT as a first-class supported exchange today. Custom or CCXT-backed implementations are the documented path.

  • Custom connector

    Your own internal trading engine or proprietary WhiteBIT integration against the REST and WebSocket APIs.

Framework support for WhiteBIT products

Coverage varies by framework. CCXT exposes WhiteBIT spot through its unified `whitebit` class; futures and margin coverage in CCXT is partial. Neither Freqtrade nor Hummingbot lists WhiteBIT as a first-class supported exchange today. Native API access reaches everything WhiteBIT publishes including futures and isolated margin.

FrameworkSpotFuturesMarginOptions
Native WhiteBIT APISupportedSupportedSupportedNot documented as supported
CCXTSupportedPartially supportedPartially supportedNot documented as supported
FreqtradeNot documented as supportedNot documented as supportedNot documented as supportedNot documented as supported
HummingbotNot documented as supportedNot documented as supportedNot documented as supportedNot documented as supported

✓ confirmed support per official framework docs. "no" indicates not officially documented as supported. "partial" indicates limited coverage. Workflow links target /workflows/ pages currently in authoring.

TradingHost does not force a framework. It runs your project.

Author with AI

The framework starters above pair naturally with AI IDEs. The TradingHost MCP control surface closes the loop: AI tools can inspect deployments, review logs and manage the runtime alongside you, never the trade execution path.

Section 04 · Run on TradingHost

Run your code on TradingHost

WhiteBIT provides the exchange and API access. TradingHost provides the production environment where your WhiteBIT-connected strategy runs.

Instead of running strategy code on a laptop, desktop machine, generic VPS or manually configured server, you deploy from GitHub into a TradingHost-managed container runtime.

You

  • Your repo contains your code.
  • Your deployment defines how it runs.
  • Your strategy connects to WhiteBIT.

TradingHost

  • Keeps the runtime online.
  • Surfaces logs and health checks.
  • Region selection.
  • Controlled deployment surface.

Deployment flow

  1. STEP 01

    Connect GitHub

    Authorise TradingHost to access your GitHub account.

  2. STEP 02

    Link a repo or start from a framework

    Point TradingHost at your existing strategy repo, or fork a TradingHost framework runtime (CCXT) for a working baseline against the WhiteBIT REST and WebSocket APIs.

  3. STEP 03

    Deploy into a TradingHost container

    Pick a region (EU or US-East), supply the environment values your strategy needs (WhiteBIT API key and secret, balance-transfer settings), and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. No local Docker install required.

  4. STEP 04

    Monitor logs and health

    Watch live logs, health and runtime state from the TradingHost dashboard. The same surface is reachable through MCP from any AI IDE, so Cursor, Claude Code or a CLI agent can read deployment state and manage the runtime alongside you.

  5. STEP 05

    Update and redeploy

    Push changes to your GitHub main branch and TradingHost redeploys automatically.

Deploy

Section 05 · Operational notes

Operational notes for WhiteBIT

Things that bite you when you actually run a WhiteBIT strategy in a containerised cloud runtime, not in WhiteBIT’s docs, not in framework READMEs. Every claim below is paraphrased from WhiteBIT’s own documentation; the deployment-side guidance is from running these strategies on TradingHost.

  1. 01 · No testnet

    WhiteBIT has no public testnet; integration testing happens on live API

    WhiteBIT does not publish a public testnet. All integration testing happens against the live production API with real assets at minimum order sizes. That is a material operational gap relative to Binance, Coinbase or Bybit, all of which run sandboxed environments for safe pre-deployment validation. The right pattern is to scope a separate small-balance account or sub-account for first-deploy testing, use the smallest legal order size, and ship code with the standard guards (idempotency keys, max-position checks, kill switch) on day one rather than after the first incident.

    SourceWhiteBIT API reference

  2. 02 · Tiered rate limits

    Per-endpoint rate limits: Main Balance 1k/10s, Trade Balance 12k/10s, Order create 10k/10s, public 2k/10s

    WhiteBIT applies per-endpoint rate limits rather than a single global budget. Main Balance endpoints: 1,000 requests per 10 seconds. Trade Balance endpoints: 12,000 per 10 seconds. Order create endpoint: 10,000 per 10 seconds. Public market endpoints: 2,000 per 10 seconds. A strategy that hammers one endpoint family does not deplete the budget for another, but does deplete its own bucket fast. Encode the endpoint-class budget in your client wrapper rather than tracking a single global counter.

    SourceWhiteBIT API reference

  3. 03 · WebSocket caps

    1,000 concurrent connections per minute; 200 messages per minute per single connection

    The WhiteBIT WebSocket layer caps overall throughput at 1,000 concurrent connection attempts per minute and 200 messages per minute per single open connection. A strategy that subscribes to many private channels on one connection can hit the per-connection cap before the orderbook is even fully subscribed. The right pattern for multi-strategy deployments is one WebSocket connection per strategy with its own message budget, rather than one shared connection routed to many consumers. Token-refresh on private channels is a client-side responsibility; lose the token and the subscription drops silently.

    SourceWhiteBIT API reference

  4. 04 · Balance-transfer codes

    Error 1 = disabled from-trade, 2 = disabled from-main, 3 = insufficient

    WhiteBIT splits balances between Main and Trade accounts. Strategies that place orders against the Trade balance but read the Main balance for funding need to call the balance-transfer endpoint. The transfer endpoint returns three specific error codes worth knowing by heart: error 1 means transfers from Trade are disabled (typically by an account-level setting), error 2 means transfers from Main are disabled, error 3 means insufficient balance. None of the three are recoverable by retry; they require either an account-level fix or a different strategy decision.

    SourceWhiteBIT API documentation repo

  5. 05 · Platform-only features

    Copy trading, auto-invest and staking have no API access

    WhiteBIT offers copy trading, auto-invest schedules and staking, but all three are platform-only features without API access. Strategies that integrate WhiteBIT cannot programmatically subscribe to a copy-trade lead, configure an auto-invest schedule, or stake balances. The right pattern is to treat these as out-of-band manual workflows that humans configure in the WhiteBIT UI, and have strategy code read the resulting balance and order state through the API.

    SourceWhiteBIT API reference

  6. 06 · Minimum order sizing

    Per-pair minimum sizes apply on live integration; query before testing

    Because there is no testnet, the first orders a strategy places are real money against real liquidity. Per-pair minimum order sizes apply, and shipping a strategy that submits below-minimum orders gets every request rejected. Query the minimum-size endpoint at startup, cache the values per symbol, and validate every outbound order against the cached minimum before submission. Re-fetch the cache periodically because WhiteBIT updates minimums per market conditions.

    SourceWhiteBIT API reference

Section 06 · Built for

Built for

TradingHost WhiteBIT runtimes are best suited to:

  • Developers building strategies in AI IDEs (Cursor, Claude Code)
  • Systematic crypto traders
  • Quant developers
  • CCXT users
  • Teams moving from VPS hosting to containerised deployment

Connecting GitHub and creating your first strategy is free.

Section 08 · FAQ

FAQ

No. TradingHost is independent and is not affiliated with WhiteBIT.

No. Your strategy code connects to WhiteBIT and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.

No. WhiteBIT API access is provided by WhiteBIT. You are responsible for your WhiteBIT account, API permissions, credentials and compliance with WhiteBIT’s terms.

No. TradingHost is the cloud runtime where your strategy code runs. We do not provide signals, AI prediction models or pre-built bots. With TradingHost you write or generate the strategy yourself (often with Cursor or Claude Code), keep it in GitHub as your code, and use TradingHost to run it in production. 3Commas, Cryptohopper and similar products own the strategy logic; TradingHost runs your strategy.

AWS and DigitalOcean give you raw compute. You handle OS updates, container orchestration, log shipping, secret rotation, region failover and uptime monitoring yourself. TradingHost gives you a managed runtime purpose-built for trading strategies: GitHub-native deployment, MCP-driven control from AI IDEs, log and health surfaces out of the box. If you want to operate the infrastructure yourself, AWS works. If you want the runtime as a managed service, TradingHost is the shorter path.

Yes. TradingHost runs Python strategies; pick the framework runtime that matches your stack or deploy your own repo.

Yes. TradingHost supports any language that can run inside a container.

Yes. CCXT ships a unified `whitebit` class that covers spot trading. Futures and margin coverage in CCXT is partial. Drop your CCXT strategy into a container, point it at GitHub, and TradingHost runs it like any other Python or Node project. See the CCXT framework runtime for the full setup story.

Yes. Perpetual futures are reachable through the WhiteBIT API once your account is eligible. TradingHost is venue-agnostic at the runtime level: any code that can authenticate against the futures endpoints can run inside a container. Note that copy trading, auto-invest and staking are platform-only features without API access; strategies cannot programmatically subscribe to a copy-trade lead or configure an auto-invest schedule.

Yes, if your project is designed that way. You can run multiple strategy processes or services inside one runtime, or separate them into different runtimes for isolation and operational clarity. For WhiteBIT specifically, prefer one WebSocket connection per strategy so each strategy gets its own per-connection 200-messages-per-minute budget rather than sharing it. See the TradingHost runtime page for the multi-strategy model.

The fastest path is to fork a TradingHost framework runtime: CCXT for a ready-to-deploy project. Or connect your own GitHub strategy repo. Linking a GitHub repo and creating a strategy is free; runtime plans are listed on the pricing page.

In your GitHub-controlled secrets workflow. TradingHost reads them at runtime through GitHub repository secrets, environment secrets or your own approved secret-management process. TradingHost does not need custody of your API key and secret. See platform secrets for the full handling model.

No. Strategies should never need withdrawal permissions. Scope your API key down to trading and account-state reads only, and keep withdrawal off the key entirely.

Yes. TradingHost supports MCP-based control for AI IDEs including Cursor, Claude Code, GitHub Copilot and CLI-based AI agents. AI tools can inspect deployments, review logs, restart strategies and manage runtime workflows. MCP is a control and observability surface, not the trade execution path. See the MCP control surface for the full picture.

Both. The MCP control surface works equally well from CLI-based agents (Claude Code CLI, custom MCP clients, scripted MCP calls) and from inside an IDE. The GitHub-native deployment loop also works without any AI tooling: a regular git push to your main branch triggers a redeploy.

The runtime detects the crash and exposes the relevant logs and health information. Where supported, the affected strategy can be restarted without disrupting other strategies running in the same container. Your strategy code is still responsible for safe error handling, duplicate-order protection and risk controls. See observability for the logs and health surface.

WhiteBIT does not publish a public testnet. All integration testing happens against the live production API with real assets at minimum order sizes. The right pattern is to scope a separate small-balance account or sub-account for first-deploy testing, use the smallest legal order size, and ship code with standard guards (idempotency keys, max-position checks, kill switch) on day one rather than after the first incident. See the Operational notes section above for the full guidance.

TradingHost runs in the EU and US-East regions. Pick the region closest to the matching engine your strategy depends on. See the regions page for routing and proximity details.

No. TradingHost is focused on production runtime and deployment. Backtesting belongs in your research stack, framework or AlgoBuilder.