Runtime natif IA pour stratégies de trading WhiteBIT
Développez dans Cursor, Claude Code ou n'importe quel IDE IA. Déployez depuis GitHub sur un runtime cloud managé avec contrôle MCP natif, logs et choix de la région.
Section 01 · En un coup d’œil
En un coup d’œil
- Plateforme
- WhiteBIT
- Type de plateforme
- Plateforme d'échange crypto (globale)
- Classe d’actifs
- Crypto
- Produits pris en charge
- Spot, contrats à terme perpétuels, marge isolée. Limites de requêtes échelonnées par endpoint ; pas de testnet public (les tests d'intégration se font sur l'API réelle avec des tailles d'ordre minimales).
- Modèle d’exécution
- Runtime de stratégie conteneurisé
- Source de déploiement
- GitHub
- Langages
- Tout langage compatible avec un conteneur
- Intégrations courantes
- API REST et WebSocket natives WhiteBIT, CCXT, connecteurs personnalisés
- Intégration du workflow d’IA
- Interface de contrôle MCP pour Cursor, Claude Code, GitHub Copilot et agents CLI
- Rôle de TradingHost
- Runtime, déploiement, logs, suivis de santé, choix de région, contrôle MCP
- Rôle de WhiteBIT
- Compte d'échange, accès API, accès au marché, lieu d'exécution
- Affiliation
- TradingHost est indépendant et n'est pas affilié à WhiteBIT
Section 02 · Ce que propose WhiteBIT
Ce que propose WhiteBIT
WhiteBIT propose le spot, les contrats à terme perpétuels et la marge isolée via des API REST et WebSocket avec des limites de requêtes échelonnées par endpoint. Réalité opérationnelle notable : il n'existe pas de testnet public, les tests d'intégration s'effectuent donc sur l'API réelle avec des tailles d'ordre minimales. Le copy trading, l'auto-invest et le staking sont réservés à la plateforme et n'ont aucun accès API. Les spécificités des endpoints évoluent avec le temps. La structure globale reste stable ; les limites de requêtes précises, les listes de symboles et les paliers de frais sont disponibles dans la documentation de WhiteBIT.
Marchés et types de stratégies
- Trading spot sur paires libellées en USDT, BTC et ETH
- Stratégies sur contrats à terme perpétuels
- Stratégies sur marge isolée
- Abonnement WebSocket jusqu'à 200 messages par minute et par connexion
- Gestion des limites de requêtes échelonnées par endpoint
- Tests d'intégration sur l'API réelle (pas de testnet public disponible)
- Flux de transfert de solde entre les comptes Trade Balance et Main Balance
- Stratégies basées sur l'API évitant les fonctionnalités exclusives à la plateforme (copy trading, auto-invest)
Interface API
- Produits couverts
- Spot, contrats à terme perpétuels et marge isolée. Le copy trading, l'auto-invest et le staking existent sur WhiteBIT mais sont réservés à la plateforme (aucun accès API). Les stratégies qui dépendent de ces fonctionnalités nécessitent une intervention humaine.
- Méthodes de connexion
- API REST pour le placement d'ordres et les requêtes de compte avec des limites échelonnées par endpoint : Main Balance 1 000 requêtes par 10 secondes, Trade Balance 12 000 par 10 secondes, création d'ordres 10 000 par 10 secondes, marchés publics 2 000 par 10 secondes. WebSocket autorise jusqu'à 1 000 connexions simultanées par minute avec 200 messages par minute pour une seule connexion.
- Authentification
- Clé API et secret par stratégie avec requêtes signées par HMAC. Les autorisations peuvent être limitées par clé. Les abonnements WebSocket aux canaux privés nécessitent un flux de rafraîchissement de jeton que le client doit gérer.
Pour plus de détails, reportez-vous à WhiteBIT
Les endpoints spécifiques, les poids des limites de requêtes, les listes de symboles, les paliers de frais et l'historique des versions se trouvent dans la documentation de WhiteBIT. Considérez-les comme la source de vérité.
Section 03 · Développer avec l’IA
Développez votre stratégie WhiteBIT avec l’IA
Choisissez une méthode d’intégration, dupliquez (fork) un starter de framework TradingHost et concevez votre stratégie dans un AI IDE. Cursor, Claude Code, GitHub Copilot et les agents IA en ligne de commande fonctionnent tous avec le même cycle de déploiement natif sur GitHub.
API WhiteBIT native
Contrôle direct du comportement spécifique à WhiteBIT, des flux de transfert de solde et des limites de requêtes échelonnées.
CCXT
Interface commune entre WhiteBIT et d'autres plateformes d'échange crypto. CCXT expose WhiteBIT via la classe unifiée `whitebit` pour le trading spot.
Freqtrade ou Hummingbot
Aucun de ces frameworks ne liste actuellement WhiteBIT parmi les échanges officiellement pris en charge. Les implémentations personnalisées ou basées sur CCXT constituent la voie documentée.
Connecteur personnalisé
Votre propre moteur de trading interne ou intégration propriétaire à WhiteBIT via les API REST et WebSocket.
Compatibilité des frameworks avec les produits WhiteBIT
La couverture varie selon le framework. CCXT expose le spot WhiteBIT via sa classe unifiée `whitebit` ; la couverture des contrats à terme et de la marge dans CCXT est partielle. Ni Freqtrade ni Hummingbot ne listent actuellement WhiteBIT comme un échange pris en charge de premier plan. L'accès natif à l'API permet d'accéder à tout ce que WhiteBIT publie, y compris les contrats à terme et la marge isolée.
✓ support confirmé selon la documentation officielle du framework. « no » indique qu'il n'est pas officiellement documenté comme pris en charge. « partial » indique une couverture limitée. Les liens de workflow pointent vers les pages /workflows/ actuellement en cours de rédaction.
TradingHost n’impose aucun framework. Il exécute votre projet.
Développer avec l’IA
Les starters de framework ci-dessus s’associent naturellement avec les AI IDE. L’interface de contrôle MCP de TradingHost ferme la boucle : les outils d’IA peuvent inspecter les déploiements, consulter les journaux et gérer l’environnement d’exécution à vos côtés, sans jamais interférer avec le flux d’exécution des ordres.
Section 04 · Exécuter sur TradingHost
Exécutez votre code sur TradingHost
WhiteBIT fournit la plateforme d’échange et l’accès API. TradingHost fournit l’environnement de production où s’exécute votre stratégie connectée à WhiteBIT.
Au lieu d’exécuter le code de votre stratégie sur un ordinateur portable, un ordinateur de bureau, un VPS générique ou un serveur configuré manuellement, vous le déployez depuis GitHub dans un environnement d’exécution de conteneurs géré par TradingHost.
Vous
- Votre dépôt contient votre code.
- Votre déploiement définit son mode d’exécution.
- Votre stratégie se connecte à WhiteBIT.
TradingHost
- Maintient l’environnement d’exécution en ligne.
- Affiche les logs et les contrôles d’état.
- Sélection de la région.
- Surface de déploiement contrôlée.
Flux de déploiement
- ÉTAPE 01
Connecter GitHub
Autorisez TradingHost à accéder à votre compte GitHub.
- ÉTAPE 02
Associez un dépôt ou démarrez depuis un framework
Pointez TradingHost vers votre dépôt de stratégie existant, ou dupliquez (fork) un runtime de framework TradingHost (CCXT) pour obtenir une base de travail opérationnelle avec les API REST et WebSocket de WhiteBIT.
- ÉTAPE 03
Déployer dans un conteneur TradingHost
Choisissez une région (EU ou US-East), renseignez les variables d'environnement requises par votre stratégie (clé API et secret WhiteBIT, paramètres de transfert de solde), puis déployez. TradingHost compile votre conteneur à partir du dépôt et exécute votre stratégie sur une infrastructure Kubernetes managée. Aucune installation locale de Docker n'est requise.
- ÉTAPE 04
Suivre les logs et l’état de santé
Suivez en direct les logs, l’état de santé et l’état d’exécution depuis le tableau de bord TradingHost. Cette même interface est accessible via MCP depuis n’importe quel AI IDE, permettant à Cursor, Claude Code ou un agent en ligne de commande de lire l’état du déploiement et de gérer le runtime à vos côtés.
- ÉTAPE 05
Mettre à jour et redéployer
Poussez vos modifications sur votre branche principale GitHub et TradingHost relance automatiquement le déploiement.
Section 05 · Notes opérationnelles
Notes opérationnelles pour WhiteBIT
Les pièges qui vous guettent lorsque vous exécutez réellement une stratégie WhiteBIT dans un runtime cloud conteneurisé, absents de la documentation de WhiteBIT ou des fichiers README des frameworks. Chaque affirmation ci-dessous est paraphrasée à partir de la propre documentation de WhiteBIT ; les conseils liés au déploiement proviennent de l'exécution de ces stratégies sur TradingHost.
01 · Pas de testnet
WhiteBIT n'a pas de testnet public ; les tests d'intégration se font sur l'API réelle
WhiteBIT ne propose pas de testnet public. Tous les tests d'intégration s'effectuent sur l'API de production réelle avec de vrais actifs et des tailles d'ordre minimales. Il s'agit d'un écart opérationnel important par rapport à Binance, Coinbase ou Bybit, qui proposent tous des environnements de test (sandbox) pour une validation sécurisée avant déploiement. La bonne approche consiste à dédier un compte ou sous-compte distinct à faible solde pour les premiers tests de déploiement, à utiliser la plus petite taille d'ordre autorisée et à déployer du code intégrant des protections standards (clés d'idempotence, vérifications de position maximale, kill switch) dès le premier jour plutôt qu'après le premier incident.
SourceWhiteBIT API reference02 · Limites de requêtes échelonnées
Limites par endpoint : Main Balance 1k/10s, Trade Balance 12k/10s, Order create 10k/10s, public 2k/10s
WhiteBIT applique des limites de requêtes par endpoint plutôt qu'un budget global unique. Endpoints Main Balance : 1 000 requêtes par 10 secondes. Endpoints Trade Balance : 12 000 par 10 secondes. Endpoint de création d'ordre : 10 000 par 10 secondes. Endpoints de marché publics : 2 000 par 10 secondes. Une stratégie qui sollicite intensivement une famille d'endpoints n'épuise pas le budget d'une autre, mais vide rapidement son propre quota. Intégrez la gestion du budget par classe d'endpoint directement dans votre wrapper client plutôt que de suivre un simple compteur global.
SourceWhiteBIT API reference03 · Limites WebSocket
1 000 connexions simultanées par minute ; 200 messages par minute par connexion unique
La couche WebSocket de WhiteBIT limite le débit global à 1 000 tentatives de connexion simultanées par minute et à 200 messages par minute pour une seule connexion ouverte. Une stratégie qui s'abonne à de nombreux canaux privés sur une seule connexion peut atteindre la limite par connexion avant même que le carnet d'ordres ne soit entièrement souscrit. Pour les déploiements multi-stratégies, la bonne approche consiste à utiliser une connexion WebSocket par stratégie avec son propre budget de messages, plutôt qu'une connexion partagée et routée vers plusieurs consommateurs. Le renouvellement des tokens sur les canaux privés relève de la responsabilité du client ; si le token est perdu, l'abonnement s'interrompt silencieusement.
SourceWhiteBIT API reference04 · Codes de transfert de solde
Erreur 1 = disabled from-trade, 2 = disabled from-main, 3 = insufficient
WhiteBIT sépare les soldes entre les comptes Main et Trade. Les stratégies qui passent des ordres sur le solde Trade mais lisent le solde Main pour le financement doivent appeler l'endpoint de transfert de solde. Cet endpoint renvoie trois codes d'erreur spécifiques à connaître par cœur : l'erreur 1 signifie que les transferts depuis Trade sont désactivés (généralement par un paramètre au niveau du compte), l'erreur 2 signifie que les transferts depuis Main sont désactivés, et l'erreur 3 indique un solde insuffisant. Aucune de ces trois erreurs ne peut être résolue par une nouvelle tentative ; elles nécessitent soit une correction au niveau du compte, soit une décision différente de la part de la stratégie.
05 · Fonctionnalités exclusives à la plateforme
Le copy trading, l'auto-invest et le staking n'ont pas d'accès API
WhiteBIT propose le copy trading, les plans d'auto-invest et le staking, mais ces trois fonctionnalités sont exclusives à la plateforme et ne disposent d'aucun accès API. Les stratégies qui s'intègrent à WhiteBIT ne peuvent pas s'abonner par programmation à un trader référent, configurer un plan d'auto-invest ou staker des soldes. La bonne approche consiste à traiter ces opérations comme des flux de travail manuels externes configurés par l'utilisateur dans l'interface de WhiteBIT, et à laisser le code de la stratégie lire le solde et l'état des ordres via l'API.
SourceWhiteBIT API reference06 · Taille minimale des ordres
Des tailles minimales par paire s'appliquent en production ; interrogez l'API avant de tester
En l'absence de testnet, les premiers ordres passés par une stratégie engagent de l'argent réel face à une liquidité réelle. Des tailles d'ordre minimales par paire s'appliquent, et déployer une stratégie qui soumet des ordres inférieurs au minimum entraînera le rejet de chaque requête. Interrogez l'endpoint des tailles minimales au démarrage, mettez en cache les valeurs par symbole et validez chaque ordre sortant par rapport au minimum mis en cache avant de le soumettre. Actualisez périodiquement ce cache, car WhiteBIT ajuste les minimums en fonction des conditions du marché.
SourceWhiteBIT API reference
Section 06 · Conçu pour
Conçu pour
Les runtimes TradingHost pour WhiteBIT sont particulièrement adaptés aux :
- Développeurs concevant des stratégies dans des IDE IA (Cursor, Claude Code)
- Traders crypto systématiques
- Développeurs quantitatifs
- Utilisateurs de CCXT
- Équipes migrant d'un hébergement VPS vers un déploiement conteneurisé
La connexion à GitHub et la création de votre première stratégie sont gratuites.
Section 08 · FAQ
FAQ
Non. TradingHost est indépendant et n'est pas affilié à WhiteBIT.
Non. Le code de votre stratégie se connecte à WhiteBIT et envoie des instructions selon votre propre logique, les autorisations de votre compte et votre méthode d'intégration. TradingHost fournit l'environnement d'exécution (runtime) dans lequel ce code s'exécute.
Non. L'accès à l'API de WhiteBIT est fourni par WhiteBIT. Vous êtes responsable de votre compte WhiteBIT, des autorisations de vos clés API, de vos identifiants et du respect des conditions d'utilisation de WhiteBIT.
Non. TradingHost est l'environnement d'exécution cloud (runtime) où s'exécute le code de votre stratégie. Nous ne fournissons pas de signaux, de modèles de prédiction IA ou de bots prêts à l'emploi. Avec TradingHost, vous écrivez ou générez vous-même votre stratégie (souvent avec Cursor ou Claude Code), vous la conservez sur GitHub sous forme de code, et vous utilisez TradingHost pour l'exécuter en production. Des produits comme 3Commas ou Cryptohopper détiennent la logique de la stratégie ; TradingHost se contente d'exécuter la vôtre.
AWS et DigitalOcean vous fournissent de la puissance de calcul brute. Vous devez gérer vous-même les mises à jour de l'OS, l'orchestration des conteneurs, la centralisation des logs, la rotation des secrets, le basculement de région et la surveillance de la disponibilité. TradingHost vous offre un environnement d'exécution managé spécialement conçu pour les stratégies de trading : déploiement natif via GitHub, contrôle piloté par MCP depuis vos IDE IA, ainsi que des interfaces de logs et de suivi de santé intégrées. Si vous souhaitez gérer l'infrastructure vous-même, AWS convient parfaitement. Si vous préférez un environnement d'exécution sous forme de service managé, TradingHost est la voie la plus rapide.
Oui. TradingHost exécute des stratégies Python ; choisissez l'environnement d'exécution de framework qui correspond à votre stack ou déployez votre propre dépôt.
Oui. TradingHost prend en charge n'importe quel langage capable de s'exécuter dans un conteneur.
Oui. CCXT propose une classe `whitebit` unifiée qui couvre le trading au comptant (spot). La couverture des futures et de la marge dans CCXT est partielle. Intégrez votre stratégie CCXT dans un conteneur, liez-la à GitHub, et TradingHost l'exécutera comme n'importe quel projet Python ou Node. Consultez la page de l'environnement d'exécution du framework CCXT pour connaître tous les détails de configuration.
Oui. Les contrats à terme perpétuels (perpetual futures) sont accessibles via l'API de WhiteBIT dès lors que votre compte y est éligible. TradingHost est agnostique vis-à-vis des plateformes au niveau de l'environnement d'exécution : tout code capable de s'authentifier auprès des endpoints de futures peut s'exécuter dans un conteneur. Notez que le copy trading, l'auto-invest et le staking sont des fonctionnalités exclusives à la plateforme sans accès API ; les stratégies ne peuvent pas s'abonner par programmation à un trader référent ni configurer un plan d'auto-invest.
Oui, si votre projet est conçu ainsi. Vous pouvez exécuter plusieurs processus ou services de stratégie au sein d'un même environnement d'exécution, ou les séparer dans différents environnements pour plus d'isolation et de clarté opérationnelle. Spécifiquement pour WhiteBIT, privilégiez une connexion WebSocket par stratégie afin que chacune dispose de son propre budget de 200 messages par minute par connexion, plutôt que de le partager. Consultez la page de l'environnement d'exécution TradingHost pour découvrir le modèle multi-stratégies.
La voie la plus rapide consiste à forker un environnement d'exécution de framework TradingHost : CCXT pour un projet prêt à être déployé. Vous pouvez également connecter votre propre dépôt de stratégie GitHub. Associer un dépôt GitHub et créer une stratégie est gratuit ; les abonnements d'environnement d'exécution sont détaillés sur la page des tarifs.
Dans votre flux de travail de secrets contrôlé par GitHub. TradingHost les lit au moment de l'exécution via les secrets de dépôt GitHub, les secrets d'environnement ou votre propre processus approuvé de gestion des secrets. TradingHost n'a pas besoin de conserver vos clés API et secrets. Consultez la section sur les secrets de la plateforme pour connaître l'intégralité du modèle de gestion.
Non. Les stratégies ne devraient jamais avoir besoin d'autorisations de retrait. Limitez la portée de votre clé API uniquement au trading et à la lecture de l'état du compte, et désactivez complètement les retraits pour cette clé.
Oui. TradingHost prend en charge le contrôle basé sur MCP pour les IDE IA, notamment Cursor, Claude Code, GitHub Copilot et les agents IA en ligne de commande (CLI). Les outils d'IA peuvent inspecter les déploiements, consulter les logs, redémarrer les stratégies et gérer les flux de travail de l'environnement d'exécution. MCP est une interface de contrôle et d'observabilité, et non le chemin d'exécution des transactions. Consultez la section sur l'interface de contrôle MCP pour en savoir plus.
Les deux. L'interface de contrôle MCP fonctionne tout aussi bien depuis des agents en ligne de commande (CLI de Claude Code, clients MCP personnalisés, appels MCP scriptés) que depuis un IDE. Le cycle de déploiement natif via GitHub fonctionne également sans aucun outil d'IA : un simple git push sur votre branche principale déclenche un redéploiement.
L'environnement d'exécution détecte le plantage et expose les logs ainsi que les informations de santé correspondantes. Lorsque cela est pris en charge, la stratégie concernée peut être redémarrée sans perturber les autres stratégies exécutées dans le même conteneur. Le code de votre stratégie reste responsable de la gestion sécurisée des erreurs, de la protection contre les ordres doublons et des contrôles de risque. Consultez la section sur l'observabilité pour en savoir plus sur l'interface de logs et de santé.
WhiteBIT ne propose pas de testnet public. Tous les tests d'intégration s'effectuent directement sur l'API de production réelle, avec de vrais actifs et des tailles d'ordre minimales. La bonne pratique consiste à dédier un compte ou sous-compte spécifique avec un faible solde pour les premiers tests de déploiement, à utiliser la taille d'ordre minimale autorisée, et à intégrer des garde-fous standards (clés d'idempotence, limites de position maximale, kill switch) dès le premier jour plutôt qu'après le premier incident. Pour en savoir plus, consultez la section Notes opérationnelles ci-dessus.
TradingHost est disponible dans les régions EU et US-East. Choisissez la région la plus proche du moteur d'appariement utilisé par votre stratégie. Consultez la page des régions pour obtenir des détails sur le routage et la proximité.
Non. TradingHost est exclusivement dédié à l'exécution en production et au déploiement. Le backtesting doit être effectué au sein de votre environnement de recherche, de votre framework ou d'AlgoBuilder.