AI-native runtime for BingX 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.
Section 01 · At a glance
At a glance
- Venue
- BingX
- Venue type
- Crypto exchange (copy-trading-led)
- Asset class
- Crypto (spot, USDT-M perpetuals, copy trading)
- Supported products
- Spot, USDT-M perpetual futures, coin-M (standard) futures, copy trading on top of perps, grid strategies. Demo trading available against a separate testnet endpoint.
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native BingX OpenAPI (REST and WebSocket), 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
- BingX role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with BingX.
Section 02 · What BingX offers
What BingX offers
BingX offers spot trading, USDT-M perpetual futures and coin-M (standard) futures through the BingX OpenAPI, plus a copy-trading layer on top of perpetuals. Strategies authenticate with HMAC-SHA256 signatures on the X-BX-APIKEY header against a sorted parameter string. Endpoint specifics change over time; BingX adjusted multiple rate-limit ceilings through 2025. The shape is durable; the precise quota numbers and symbol lists live in BingX's docs.
Markets and strategy patterns
- USDT-M perpetual futures strategies
- Coin-M (standard) futures strategies
- Copy-trading parent and follower account flows
- Funding-rate and basis trading on perpetuals
- Spot strategies across BingX listings
- Grid trading via OpenAPI
- WebSocket private channel order and balance streams
- Demo-trading-validated deployments against the testnet endpoint
API surface
- Product surfaces
- Spot, USDT-M perpetual futures and coin-M (standard) futures via the BingX OpenAPI. Copy-trading hierarchies sit on top of perps. A separate demo-trading endpoint exists for validation against a testnet that mirrors the production surface with distinct keys.
- Connection methods
- REST for order placement and account queries on the openApi path family. WebSocket streams for real-time market data, depth and trades. WebSocket private channels for account, balance and order events.
- Authentication
- API key and secret per strategy. Private requests carry the X-BX-APIKEY header and an HMAC-SHA256 signature against a sorted ASCII parameter string with millisecond timestamp. Signatures are emitted in lowercase hex. Permissions are scoped per key (read, spot trade, futures trade, withdrawal). Strategies should never need withdrawal permission.
For specifics, refer to BingX
Specific endpoints, rate-limit weights, symbol lists, fee tiers and version history live in BingX's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your BingX 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 BingX OpenAPI
Direct control over BingX-specific behaviour, copy-trading hierarchies and order execution logic.
Hummingbot
Framework-based deployments using Hummingbot strategy structure and configuration model.
Custom connector
Your own internal trading engine or proprietary BingX integration.
Framework support for BingX products
Coverage varies by framework. CCXT spans BingX spot and perpetuals; Hummingbot's bingx_perpetual connector targets USDT-M perps without spot support; Freqtrade does not list BingX as a supported exchange. Copy-trading endpoints are a native-API-only concern today; no framework abstracts them as a first-class primitive.
✓ 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
BingX provides the exchange and API access. TradingHost provides the production environment where your BingX-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 BingX.
TradingHost
- Keeps the runtime online.
- Surfaces logs and health checks.
- Region selection.
- Controlled deployment surface.
Deployment flow
- STEP 01
Connect GitHub
Authorise TradingHost to access your GitHub account.
- 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.
- STEP 03
Deploy into a TradingHost container
Pick a region (EU or US-East), supply the environment values your strategy needs (BingX API keys, etc.), and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. No local Docker install required.
- 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.
- STEP 05
Update and redeploy
Push changes to your GitHub main branch and TradingHost redeploys automatically.
Section 05 · Operational notes
Operational notes for BingX
Things that bite you when you actually run a BingX strategy in a containerised cloud runtime, not in BingX's docs, not in framework READMEs. Every claim below is quoted or paraphrased from BingX's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · Oct 2025 rate limits
Swap trade order endpoint now 10 req/sec; account interface 2,000 req / 10 sec
BingX published a rate-limit upgrade on October 14, 2025 raising the swap trade order endpoint at /openApi/swap/v2/trade/order from 5 to 10 requests per second per IP. The account-interface ceiling for IP-level traffic was raised to 2,000 requests per 10 seconds from September 10, 2025. Integrations sized against older guides may now be running well below the available ceiling, or, in the opposite direction, may have been written against a more permissive limit that has since been tightened. Size your concurrency model against the October 2025 numbers and re-check the announcement feed every few months.
02 · Three-element auth
X-BX-APIKEY header, sorted-string signature, millisecond timestamp
BingX private requests carry the X-BX-APIKEY header (your API key) and an HMAC-SHA256 signature whose canonical input is the sorted-ASCII parameter string with the timestamp parameter in milliseconds. Signatures are emitted in lowercase hex. Common silent failures: timestamp in seconds rather than milliseconds, parameters in insertion order rather than sorted, uppercase hex output, or signing the wrong path component. Pin a battle-tested SDK or unit-test the signing path against a known-good request before shipping.
03 · Auto-recovery window
10-minute auto-recovery after IP or UID throttle; no manual recovery endpoint
When a strategy exceeds an IP or UID rate-limit ceiling, BingX returns 429 responses and continues to refuse signed requests for a 10-minute auto-recovery window. There is no manual recovery endpoint to escape the throttle early. The right pattern is to detect the 429 in your client, apply a respectful backoff for at least 10 minutes (longer if the throttle was severe), and resume traffic at a known-safe rate rather than retrying aggressively into a still-cooling-down quota.
04 · Demo-trading split
Demo trading lives on a separate testnet with distinct rate limits and keys
BingX exposes demo trading against a separate testnet endpoint. The key set, balances and positions are isolated from production, and the demo testnet enforces its own rate-limit ceilings. 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.
05 · Security history
September 2024 breach prompted credential rotation and security upgrades
BingX disclosed a security incident in September 2024 and rotated affected user credentials in the aftermath. Strategies running against pre-incident keys had to re-issue keys; rate-limit structure also changed multiple times through 2025 as part of the broader hardening pass. Treat BingX as an exchange whose security posture is actively evolving: rotate keys periodically, keep withdrawal-capable credentials off any cloud runtime, and watch the announcement feed for breaking changes.
06 · Key scoping
One scoped key per strategy, never one master key shared across strategies
BingX 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. IP whitelisting is also available per key.
Section 06 · Built for
Built for
TradingHost BingX 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 BingX.
No. Your strategy code connects to BingX and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. BingX API access is provided by BingX. You are responsible for your BingX account, API permissions, credentials and compliance with BingX’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 BingX spot and swap surfaces through the unified `bingx` class. Copy-trading endpoints are not a first-class CCXT primitive, so copy-trading flows run against the native BingX OpenAPI. See the CCXT framework runtime for the full setup story.
TradingHost is venue-agnostic at the runtime level: any code that can authenticate against BingX can run inside a container, including a strategy hosted on a BingX 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 and secret. 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.
BingX adjusted multiple rate-limit ceilings through 2025. The October 14, 2025 upgrade raised the swap trade order endpoint at /openApi/swap/v2/trade/order from 5 to 10 requests per second per IP; the account-interface ceiling was raised to 2,000 requests per 10 seconds from September 10, 2025. Integrations sized against older guides may have been written against a more permissive limit that has since been tightened, or against a stricter limit that has since been raised. When a strategy gets throttled, BingX enforces a 10-minute auto-recovery window with no manual recovery endpoint. Re-size against the current October 2025 numbers and back off respectfully. 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.