Read time … min

AI-native runtime for Bitget 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
Bitget
Venue type
Crypto exchange (copy-trading-led)
Asset class
Crypto (spot, USDT-M and coin-M perpetuals, margin, copy trading)
Supported products
Spot, USDT-M perpetual futures, coin-M perpetual futures, USDC-M perpetuals, isolated and cross margin, copy trading on top of perps. Demo trading available against the production API surface.
Runtime model
Containerised strategy runtime
Deployment source
GitHub
Languages
Any language that runs in a container
Common integrations
Native Bitget V2 REST and WebSocket, CCXT, Hummingbot, 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
Bitget role
Exchange account, API access, market access, execution venue
Affiliation
TradingHost is independent and is not affiliated with Bitget.

Section 02 · What Bitget offers

What Bitget offers

Bitget offers spot, USDT-M, coin-M and USDC-M perpetual futures, cross and isolated margin, and a copy-trading layer on top of perpetuals via REST and WebSocket APIs. Strategies authenticate with HMAC-SHA256-signed three-header requests against the V2 API. Endpoint specifics change over time. The shape is durable; precise rate-limit weights, fee tiers and symbol lists live in Bitget's docs.

Markets and strategy patterns

  • USDT-M perpetual futures strategies
  • Coin-M and USDC-M perpetual strategies
  • Copy-trading parent and follower account flows
  • Funding-rate and basis trading on perpetuals
  • Spot and margin strategies (cross or isolated)
  • Sub-account-isolated multi-strategy deployments
  • WebSocket private channel order and position streams
  • Demo-trading-validated deployments against the production API

API surface

Product surfaces
Spot, USDT-M perpetual futures, coin-M perpetuals, USDC-M perpetuals, isolated and cross margin, and copy-trading parent/follower hierarchies. Demo trading exposes the same V2 surface for validation against the production API without real capital.
Connection methods
REST for order placement and account queries. WebSocket public channels for market data and orderbook updates. WebSocket private channels for account, balance, position and order events. Bitget V2 is the current API generation; legacy V1 endpoints remain documented but new integrations target V2.
Authentication
API key, secret and passphrase per strategy. Private requests carry three headers: ACCESS-KEY, ACCESS-TIMESTAMP and ACCESS-SIGN. The signature is a base64-encoded HMAC-SHA256 of timestamp + method + requestPath + body. Bitget rejects requests outside a 30-second timestamp freshness window.

For specifics, refer to Bitget

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

Section 03 · Build with AI

Build your Bitget 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 Bitget V2 API

    Direct control over Bitget-specific behaviour, copy-trading hierarchies and order execution logic.

  • CCXT

    Common interface across Bitget and other crypto exchanges.

    Get started with CCXT

  • Hummingbot

    Framework-based deployments using Hummingbot strategy structure and configuration model.

    Get started with Hummingbot

  • Custom connector

    Your own internal trading engine or proprietary Bitget integration.

Framework support for Bitget products

Coverage varies by framework. CCXT spans Bitget spot and perpetuals; Hummingbot ships a dedicated bitget_perpetual connector alongside spot. Copy-trading hierarchies are a native-API-only concern today; no framework abstracts them as a first-class primitive. Native Bitget V2 covers everything Bitget offers including copy-trading.

FrameworkSpotPerpMarginCopy
Native Bitget V2SupportedSupportedSupportedSupported
CCXTSupportedSupportedPartially supportedNot documented as supported
HummingbotSupportedSupportedNot documented as supportedNot documented as supported
FreqtradeNot 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.

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

Bitget provides the exchange and API access. TradingHost provides the production environment where your Bitget-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 Bitget.

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 or Hummingbot) for a working baseline.

  3. STEP 03

    Deploy into a TradingHost container

    Pick a region (EU or US-East), supply the environment values your strategy needs (Bitget API key, secret and passphrase, etc.), 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 Bitget

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

  1. 01 · Three-header auth

    ACCESS-KEY, ACCESS-TIMESTAMP, ACCESS-SIGN are all required

    Bitget V2 private requests carry three headers: ACCESS-KEY (your API key), ACCESS-TIMESTAMP (current Unix millisecond timestamp) and ACCESS-SIGN (base64-encoded HMAC-SHA256 of timestamp + method + requestPath + body, signed with your secret key). A fourth header, ACCESS-PASSPHRASE, is required on every signed request. Strategies that omit any of the four return 40009 invalid signature errors. The passphrase is set when the key is created and cannot be retrieved later; if lost, the only path is to issue a new key.

    SourceBitget API signature reference

  2. 02 · 30-second window

    ACCESS-TIMESTAMP outside the 30-second freshness window is rejected

    Bitget rejects any signed request whose ACCESS-TIMESTAMP is more than 30 seconds away from Bitget server time. Containers with clock drift greater than 30 seconds will see signed requests refused server-side regardless of signature validity. TradingHost runtimes are NTP-synced so the 30-second tolerance is comfortable, but a container that drifts (for example after a long network partition) needs its clock resynced before it can sign requests successfully.

    SourceBitget API signature reference

  3. 03 · V1 to V2

    V2 is the current API generation; V1 endpoints remain documented but should not be the target of new integrations

    Bitget published the V2 API surface to consolidate spot, USDT-M, coin-M and copy-trading endpoints under a single signing scheme and base path. V1 endpoints remain in the docs for backward compatibility but the release-notes feed tracks deprecations against V2. New strategies should target V2 endpoints directly so the integration does not inherit a deprecation timer. Pin the API version in your client so a future V3 cutover is an explicit migration, not a silent breakage.

    SourceBitget V2 release notes

  4. 04 · Copy-trading hierarchy

    Parent and follower sub-accounts inherit stpGroupId; strategies need to be aware which side they are running on

    Bitget copy-trading positions inherit stpGroupId between a trader (parent) account and its followers. A strategy running inside a parent account that opens a position triggers copy-fills on every linked follower account, weighted by the follower configuration. Strategies that should not be copied have to run on a non-trader account, or explicitly opt out at the position level. The blast radius of a misconfigured copy-trading parent is large; sub-account isolation and per-key permission scoping are the right containment patterns.

    SourceBitget API introduction

  5. 05 · Key scoping

    One scoped key per strategy, never one master key shared across strategies

    Bitget API keys carry per-permission scoping (read, spot trade, futures trade, withdrawal). Strategies should never need withdrawal scope; isolate withdrawal-capable keys on a separate manually-managed credential outside the container runtime. Per-strategy keys with only the scopes that strategy needs contain the blast radius if a key leaks. Bitget also supports IP whitelisting per key; pin it where the runtime egress range is known and stable for your selected region.

    SourceBitget API introduction

  6. 06 · Demo trading split

    Demo trading shares the V2 surface but issues separate keys and balances

    Bitget exposes demo trading against the production V2 endpoint surface; the request shape is the same, but the key set, balances and positions are isolated from production. A common silent failure is shipping demo-validated code to production without swapping the key set, or vice versa. Keep demo and production secrets in separate TradingHost Secrets entries; never reuse one across environments.

    SourceBitget API introduction

Section 06 · Built for

Built for

TradingHost Bitget runtimes are best suited to:

  • Developers building strategies in AI IDEs (Cursor, Claude Code)
  • Systematic crypto traders
  • Quant developers
  • CCXT and Hummingbot 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 Bitget.

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

No. Bitget API access is provided by Bitget. You are responsible for your Bitget account, API permissions, credentials and compliance with Bitget’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 exposes Bitget spot and perpetual surfaces through the unified `bitget` class. Copy-trading endpoints are not a first-class CCXT primitive, so copy-trading flows run against the native Bitget V2 API. See the CCXT framework runtime for the full setup story.

TradingHost is venue-agnostic at the runtime level: any code that can authenticate against Bitget can run inside a container, including a strategy hosted on a Bitget copy-trading parent account. The implication you have to design for is that any position your strategy opens triggers copy-fills on every linked follower account, weighted by their configuration. Run copy-eligible strategies on a separate sub-account from any non-public strategies, and isolate API keys per strategy so the blast radius is contained.

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. See the TradingHost runtime page for the multi-strategy model.

The fastest path is to fork a TradingHost framework runtime: CCXT or Hummingbot 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, secret and passphrase. See platform secrets for the full handling model.

No. Strategies should never need withdrawal permissions. Use scoped permissions (read, spot trade, futures trade) and IP whitelisting where appropriate.

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.

Bitget 40009 means the signature your strategy sent does not match the expected HMAC-SHA256 of timestamp + method + requestPath + body, signed with your secret. The common causes are a missing or wrong ACCESS-PASSPHRASE header, ACCESS-TIMESTAMP outside the 30-second freshness window, signing with the wrong secret (test key vs production), or signing the wrong canonical request body (extra whitespace, key reordering). Pin a battle-tested SDK or unit-test the signing path against the Bitget signature reference. 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.