Compatibilité de l'API WEEX : Ce qui change lors d'une migration depuis une autre plateforme

Si vous avez déjà écrit du code d'intégration pour Binance, OKX ou Bitget, la seule chose que vous voulez vraiment savoir sur WEEX est la suivante : que pouvez-vous réutiliser et que devez-vous réécrire ? Plutôt que de lister les endpoints, cet article examine la compatibilité de l'API WEEX selon trois axes — le style d'authentification, la couche unifiée ccxt et le versionnage spot/contrats — et se termine par une liste de contrôle pour savoir quoi modifier lors de votre migration. L'accent est mis sur les deux éléments qui posent problème en pratique : la manière d'appeler l'API et la gestion des permissions et des clés.

En résumé : la conception de l'authentification de WEEX appartient à la famille OKX / Bitget (HMAC pré-signé encodé en Base64 plus une phrase de passe), et non au style "signature de chaîne de requête" de Binance. Saisissez ce fait et vous pourrez estimer l'effort de migration avec précision.

À quoi fait réellement référence la "Compatibilité de l'API WEEX"

La "compatibilité" ici comporte trois couches — ne les confondez pas :

• Compatibilité d'authentification — si l'algorithme de signature, les en-têtes et le format d'horodatage correspondent à la plateforme que vous connaissez, ce qui détermine si votre module de signature doit être réécrit.
• Compatibilité d'abstraction — si une bibliothèque unifiée comme ccxt permet à une base de code de fonctionner sur plusieurs plateformes.
• Compatibilité de version interne — si le spot et les contrats de WEEX, ainsi que la V2 et la V3, partagent les mêmes champs et chemins, ce qui détermine votre effort lors du passage d'un produit à l'autre chez WEEX.

Déterminez quelle couche vous migrez, puis lisez les comparaisons ci-dessous.

Compatibilité d'authentification : Style WEEX vs Binance vs OKX

C'est la partie la plus difficile de toute migration. Selon ses documents de signature, WEEX construit une chaîne de pré-signature de timestamp + method + path + body, exécute HMAC SHA256, encode la sortie en Base64 et la transmet via quatre en-têtes ACCESS-*. Le tableau présente les trois styles principaux côte à côte (données WEEX issues des documents officiels, en juillet 2026 ; les autres sont des conventions publiques largement documentées pour chaque plateforme) :

En résumé : lors d'une migration depuis OKX ou Bitget vers WEEX, la logique de signature est presque du copier-coller — vous renommez principalement les en-têtes. Migrer depuis Binance signifie réécrire le module de signature : Binance signe les paramètres de requête, produit de l'hexadécimal et n'utilise pas de phrase de passe, un modèle totalement différent du pré-sign en Base64 de WEEX. WEEX utilisant un horodatage en millisecondes, il est plus proche de Binance que du format ISO d'OKX, et ce genre de détail est le plus facile à oublier lors d'une migration.

ccxt peut-il rendre WEEX compatible immédiatement ?

Oui, et c'est le moyen le moins douloureux de contourner les différences d'authentification. La bibliothèque open-source ccxt inclut déjà WEEX, couvrant le spot, les contrats (swap) et WebSocket via plus de 80 méthodes unifiées. Si vous utilisez déjà ccxt avec une autre plateforme, passer à WEEX consiste essentiellement à changer un nom de classe et trois champs d'identification :

import ccxt

ex = ccxt.weex({
    "apiKey": "votre-APIKey",
    "secret": "votre-SecretKey",
    "password": "votre-Passphrase",   # Phrase de passe WEEX → "password" dans ccxt
})
print(ex.fetch_ticker("BTC/USDT"))

fetch_ticker, fetch_balance et create_order sont identiques sur toutes les plateformes, donc la couche métier change à peine. L'avertissement est que ccxt est une abstraction communautaire : le nommage des symboles (BTC/USDT vs BTCUSDT), la précision et les champs de frais sont normalisés par ccxt, mais si WEEX lance un nouvel endpoint, la couverture de ccxt peut accuser un retard — vérifiez par rapport à l'introduction à l'API WEEX lorsque vous recherchez de nouvelles fonctionnalités.

Compatibilité des versions Spot et Contrats (V2 / V3 BETA)

Il existe également une question de compatibilité interne chez WEEX lorsque vous croisez les produits. Les API spot et contrats sont toutes deux en V3 (BETA), les contrats conservant également la V2. Deux conclusions en découlent :

• Le spot et les contrats partagent la même authentification ACCESS-* et la même signature HMAC SHA256 + Base64, donc le module d'authentification est réutilisable sur les deux lignes de produits — seuls les chemins et les champs métier diffèrent.
• Le fait que les contrats fonctionnent en V2 parallèlement à la V3 signifie que le code hérité peut reposer sur la V2. Comme la V3 est toujours étiquetée BETA, confirmez la version dont vous dépendez avant un lancement en production et abonnez-vous au journal des modifications pour éviter d'être surpris par un changement de champ BETA.

En une ligne : la compatibilité d'authentification interne de WEEX est forte ; ce qu'il faut surveiller, c'est le statut "BETA" et le rythme de migration des versions.

Quel code modifier lors de la migration vers WEEX

Décomposé en une liste de contrôle exploitable, l'effort varie considérablement selon la source :

Quelle que soit la source, trois paramètres spécifiques à WEEX doivent être respectés : un horodatage décalé de plus de 30 secondes par rapport au serveur est rejeté ; les endpoints publics autorisent environ 20 requêtes par 2 secondes et renvoient une erreur HTTP 429 en cas d'excès ; les règles générales se trouvent dans le document des spécifications standard.

La couche de compatibilité est-elle sûre ? Notes sur la migration des permissions et des clés

L'élément le plus souvent "oublié" lors d'une migration entre plateformes est la configuration de sécurité — les mauvaises habitudes d'une ancienne plateforme deviennent une responsabilité dès qu'elles sont appliquées à une nouvelle clé. La prise en charge du trading par API par WEEX et ses conseils de sécurité officiels sont couverts dans l'explication du trading par API WEEX. Pendant la migration, vérifiez :

• Ré-minimisez les permissions — les clés WEEX sont par défaut en Read Only, et l'accès au trading est manuel ; n'ouvrez pas tout par commodité et ne conservez pas l'habitude de l'"accès complet" d'une ancienne plateforme.
• Ré-liez la liste blanche IP — après avoir changé les IP de sortie du serveur, liez-les à nouveau ; WEEX signale explicitement les clés sans liaison IP comme un risque.
• La phrase de passe est un nouveau champ — les équipes migrant depuis Binance oublient régulièrement que WEEX exige une phrase de passe qui ne peut être récupérée si elle est perdue ; intégrez-la dans votre flux de secrets.
• Pas de permission de retrait par défaut — cela limite les dommages en cas de vol de clé, mais ce n'est pas une raison pour relâcher la gestion de la SecretKey.

Le verdict

La compatibilité de l'API WEEX se résume en une phrase : l'authentification appartient à la famille OKX / Bitget, ccxt couvre les différences, et le spot et les contrats partagent un schéma de signature en interne. Migrer depuis ccxt ou une plateforme de la même famille est presque indolore ; depuis Binance, il s'agit principalement de réécrire la signature et d'ajouter une phrase de passe. L'investissement supplémentaire réel n'est pas l'intégration, mais la refonte de la configuration de sécurité (moindre privilège, liste blanche IP, gestion de la phrase de passe) dans le nouvel environnement. Pour commencer la comparaison, travaillez à partir de l'introduction à l'API WEEX.

Lecture complémentaire : la couverture des méthodes WEEX par ccxt se trouve dans son wiki officiel.

FAQ

1. L'API WEEX est-elle compatible avec l'API Binance ?

Pas au niveau de la signature. Binance signe une chaîne de requête, produit de l'hexadécimal et n'utilise pas de phrase de passe ; WEEX pré-signe timestamp + method + path + body, produit du Base64 après HMAC SHA256 et exige une phrase de passe. Migrer depuis Binance signifie réécrire le module de signature.

2. L'API WEEX est-elle compatible avec OKX ou Bitget ?

Très proche. Tous trois utilisent le style pré-sign Base64 + phrase de passe avec des en-têtes ACCESS-*, donc la logique de signature est largement réutilisable. La différence principale est qu'OKX utilise un horodatage ISO-8601 tandis que WEEX utilise une époque en millisecondes.

3. ccxt peut-il se connecter à WEEX et à d'autres plateformes en même temps ?

Oui. ccxt inclut déjà WEEX (spot, contrats, WebSocket), et les mêmes méthodes fetch_ticker, create_order et similaires fonctionnent sur toutes les plateformes — changer de plateforme ne modifie que la classe instanciée et les identifiants.

4. Le spot et les contrats WEEX peuvent-ils partager une même base de code d'authentification ?

Oui. Les deux lignes de produits utilisent les mêmes en-têtes ACCESS-* et la même signature HMAC SHA256 + Base64, donc le module d'authentification est réutilisable ; seuls les chemins de requête et les champs métier diffèrent. Les deux sont en V3 (BETA), les contrats étant également en V2.

5. Quel élément de sécurité est le plus souvent oublié lors de la migration vers WEEX ?

Trois : oublier de lier à nouveau la liste blanche IP ; oublier la phrase de passe en venant d'une plateforme sans phrase de passe comme Binance ; et conserver une clé "accès complet". Les clés WEEX sont par défaut en lecture seule sans permission de retrait, donc ajustez au moindre privilège en conséquence.

Avertissement sur les risques

Les actifs numériques sont très volatils, et le trading automatisé ou inter-plateformes via API peut entraîner la perte d'une partie ou de la totalité de votre capital en raison de failles de stratégie, de mouvements brusques du marché ou de défaillances du système. La migration et les configurations multi-plateformes ajoutent des risques spécifiques : une mauvaise configuration de la signature ou de l'horodatage peut entraîner des ordres échoués ou dupliqués ; une clé divulguée sans liaison IP peut permettre à un attaquant d'agir sur votre compte ; s'appuyer sur une abstraction tierce comme ccxt signifie que son mappage de champs ou son retard de version peut diverger du comportement réel de la plateforme ; et l'effet de levier sur les contrats amplifie les pertes. Appliquez des permissions de moindre privilège, reconfigurez la liste blanche IP et la phrase de passe par plateforme, et validez la compatibilité avec de petits montants avant la production. Cet article est une comparaison technique et ne constitue pas un conseil en investissement.