SDK Python pour l'API WEEX : Comment signer et appeler de bout en bout

La première chose à régler, avant tout code : en juillet 2026, WEEX ne propose pas de package officiel autonome appelé "weex-python-sdk". Vous disposez en réalité de deux chemins possibles : appeler les endpoints REST directement avec requests en utilisant les règles de signature de WEEX, ou utiliser la bibliothèque open-source multi-exchange ccxt, qui inclut déjà WEEX. Ce guide parcourt les deux chemins jusqu'à leur terme et consacre l'essentiel de son contenu aux deux points qui font échouer les intégrations : comment signer une requête et comment sécuriser les clés.

Ceci est une note technique que vous pouvez copier dans un projet, pas un dictionnaire d'endpoints. Les API spot et contrats de WEEX sont actuellement en V3 (BETA), avec la V2 toujours disponible pour les contrats ; le code ci-dessous utilise le spot V3.

Ce que signifie réellement "SDK Python pour l'API WEEX"

Strictement parlant, il ne s'agit pas d'un package officiellement approuvé ; c'est un raccourci pour "un client Python qui communique avec les endpoints WEEX". WEEX expose des interfaces REST et WebSocket couvrant le spot, les contrats, le copy trading et les produits de courtage. Tout langage capable d'envoyer une requête HTTP et de calculer une signature HMAC peut s'intégrer.

En pratique, le "SDK Python" prend trois formes :

• Un wrapper léger écrit à la main — requests plus hmac, quelques dizaines de lignes, dépendances minimales, contrôle maximal.
• La bibliothèque unifiée ccxt — pip install ccxt, traitez WEEX comme l'un des 100+ exchanges supportés par ccxt, avec des noms de méthodes partagés entre les plateformes.
• Un client WebSocket — websocket-client pour s'abonner aux données de marché en direct ou aux canaux privés.

L'introduction à l'API elle-même indique aux développeurs de s'aligner sur les schémas documentés et de maintenir des clients versionnés ; en d'autres termes, vous assemblez le SDK ; vous n'attendez pas qu'un officiel soit disponible.

Préparation : Créer une clé API et définir ses permissions

Avant tout appel, créez une clé API dans votre compte. Selon les documents de préparation à l'intégration, un compte peut contenir jusqu'à 10 groupes de clés. Chaque clé vous donne trois identifiants, aucun n'est optionnel :

Les permissions sont importantes ici : une clé nouvellement créée est par défaut en Read Only (lecture seule) — vous devez activer manuellement le trading spot pour passer des ordres. Liez une liste blanche d'IP lors de la création ; la documentation indique clairement que les clés sans restriction et sans liaison IP constituent un risque de sécurité.

Comment appeler : Signer une requête en Python

La règle de signature de WEEX, issue des documents de signature, concatène timestamp + méthode (majuscules) + chemin de la requête (avec paramètres) + corps, exécute HMAC SHA256 avec votre SecretKey, puis encode le résultat en Base64. Le timestamp est en millisecondes, et toute requête décalée de plus de 30 secondes par rapport à l'horloge du serveur est rejetée.

Ceci fonctionne tel quel (en utilisant l'endpoint de profondeur des documents) :

import time, hmac, hashlib, base64, requests

API_KEY    = "votre-APIKey"
SECRET_KEY = "votre-SecretKey"
PASSPHRASE = "votre-Passphrase"
BASE = "https://api-spot.weex.com"  # confirmez l'hôte avec le document officiel StandardSpecifications

def sign(ts, method, path, body=""):
    prehash = f"{ts}{method.upper()}{path}{body}"
    mac = hmac.new(SECRET_KEY.encode(), prehash.encode(), hashlib.sha256)
    return base64.b64encode(mac.digest()).decode()

def request(method, path, body=""):
    ts = str(int(time.time() * 1000))
    headers = {
        "ACCESS-KEY": API_KEY,
        "ACCESS-SIGN": sign(ts, method, path, body),
        "ACCESS-TIMESTAMP": ts,
        "ACCESS-PASSPHRASE": PASSPHRASE,
        "Content-Type": "application/json",
    }
    url = BASE + path
    if method == "GET":
        return requests.get(url, headers=headers).json()
    return requests.post(url, headers=headers, data=body).json()

# Les données de marché publiques ne nécessitent pas de signature ; ceci montre le modèle d'en-tête signé
print(request("GET", "/api/v3/market/depth?symbol=BTCUSDT&limit=20"))

Le piège : les paramètres GET vont dans la requête à l'intérieur de path, POST utilise un corps JSON, et le corps que vous signez doit être identique octet pour octet au corps que vous envoyez. Un ordre de clés différent ou un espace supplémentaire casse la signature — c'est la source la plus courante d'erreurs 401 dans les clients écrits à la main.

Utilisez ccxt pour un démarrage rapide (le meilleur choix pour la plupart)

Si vous préférez ne pas gérer la signature manuellement, ccxt enveloppe déjà les services spot, contrats (swap) et WebSocket de WEEX via plus de 80 méthodes. Quelques lignes vous permettent d'obtenir des tickers et des ordres :

import ccxt   # pip install ccxt

ex = ccxt.weex({
    "apiKey": "votre-APIKey",
    "secret": "votre-SecretKey",
    "password": "votre-Passphrase",   # La passphrase WEEX correspond au "password" de ccxt
})

print(ex.fetch_ticker("BTC/USDT"))            # données de marché
# print(ex.fetch_balance())                    # nécessite la permission de trading
# ex.create_order("BTC/USDT", "limit", "buy", 0.001, 30000)

Le gain : le même code qui appelle WEEX aujourd'hui peut appeler une autre plateforme demain avec un changement de classe d'une ligne. Le coût est que ccxt est une abstraction maintenue par la communauté ; la couverture d'un nouvel endpoint WEEX peut être en retard, vérifiez donc les champs avec les documents officiels lorsque vous poursuivez de nouvelles fonctionnalités.

Données en direct : Se connecter au WebSocket depuis Python

Le polling REST atteindra rapidement les limites de taux. Pour des données en temps réel, utilisez WebSocket ; le canal public est wss://ws-spot.weex.com/v3/ws/public et le canal privé est .../private, ce dernier étant authentifié avec les quatre mêmes champs ACCESS-KEY / ACCESS-SIGN / ACCESS-TIMESTAMP / ACCESS-PASSPHRASE (la chaîne de signature est timestamp + /v3/ws/private).

import json, websocket   # pip install websocket-client

ws = websocket.create_connection("wss://ws-spot.weex.com/v3/ws/public")
ws.send(json.dumps({"method": "SUBSCRIBE", "params": ["BTCUSDT@ticker"], "id": 1}))
print(ws.recv())

Le serveur envoie des messages ping périodiques ; le client doit répondre {"method":"PONG","id":1} sinon la connexion est coupée. Les détails des champs se trouvent dans les documents WebSocket.

Est-ce sûr ? Permissions et hygiène des clés en pratique

Le trading par API est aussi sûr que votre gestion des clés, pas que l'interface. Presque toutes les pertes proviennent de clés mal gérées plutôt que d'une interface piratée. La liste de contrôle pratique :

• Privilège minimum — n'activez que ce dont la stratégie actuelle a besoin. Une clé en lecture seule n'obtient jamais l'accès au trading ; les clés WEEX n'ont pas non plus de permission de retrait par défaut, ce qui limite ce qu'une clé volée peut faire.
• Liez une liste blanche d'IP — verrouillez la clé à l'IP de sortie de votre serveur pour qu'une clé divulguée soit inutile ailleurs.
• Gardez les clés hors du code — utilisez des variables d'environnement ou un gestionnaire de secrets ; ne codez jamais en dur, ne committez jamais sur Git, et n'expédiez jamais dans le code côté client.
• Séparez développement et production — deux ensembles de clés, pas de contamination croisée, triage d'incidents plus facile.
• Rotation planifiée — changez les clés et configurez des alertes pour les échecs de signature et les erreurs 429.

Concevez pour les limites de taux dès le départ : les endpoints de marché publics autorisent environ 20 requêtes toutes les 2 secondes, et dépasser cela renvoie une erreur HTTP 429 ; les endpoints privés suivent des règles par clé. Intégrer les tentatives et le backoff dans le client est préférable à la gestion des crises ultérieure.

Référence rapide

L'essentiel

Il n'existe pas de SDK Python officiel autonome pour l'API WEEX, et ce n'est pas un obstacle : la logique de signature est propre (HMAC SHA256 + Base64), et ccxt vous offre un point d'entrée unifié prêt à l'emploi. Ce qui décide du résultat, c'est la gestion des permissions et des clés (par défaut en lecture seule, liaison IP, garder les secrets hors du repo) et, avec cela, l'intégration Python de l'API WEEX est à la fois rapide et stable. Lorsque vous êtes prêt, créez votre première clé à partir des documents de préparation à l'intégration.

Lecture complémentaire : la couverture WEEX de ccxt est documentée dans son wiki officiel.

FAQ

1. WEEX a-t-il un SDK Python officiel ?

Pas en juillet 2026. WEEX fournit des interfaces REST et WebSocket ; côté Python, vous écrivez un wrapper requests ou utilisez ccxt, qui inclut déjà WEEX.

2. Mes appels renvoient constamment une erreur de signature (401) — comment la déboguer ?

Généralement l'une de ces trois choses : le timestamp n'est pas en millisecondes ou est décalé de plus de 30s par rapport au serveur ; l'ordre de la chaîne de signature est faux (doit être timestamp + méthode + chemin + corps) ; ou le corps signé diffère du corps réellement envoyé sur un POST. Vérifiez chacun à tour de rôle.

3. Où va la passphrase WEEX dans ccxt ?

Dans le champ password. ccxt utilise apiKey, secret et password pour mapper vers APIKey, SecretKey et Passphrase de WEEX.

4. Les endpoints de marché publics ont-ils besoin d'une signature ?

Les endpoints publics comme les données de marché ne nécessitent généralement pas de signature ; seuls les endpoints privés touchant votre compte ou vos ordres nécessitent l'ensemble complet des quatre en-têtes d'auth. Les endpoints publics sont toujours limités en taux.

5. Pourquoi ma nouvelle clé API ne peut-elle pas passer d'ordres ?

Parce qu'une nouvelle clé est par défaut en Read Only. Activez manuellement la permission de trading spot lors de la création ou de la modification de la clé, et liez une liste blanche d'IP en même temps.

Avertissement sur les risques

Les actifs numériques sont très volatils et le trading automatisé peut entraîner la perte d'une partie ou de la totalité de votre capital en raison de failles de stratégie, de fluctuations du marché ou de défaillances du système. Le trading par API ajoute des risques spécifiques : une clé divulguée sans liaison IP peut permettre à un attaquant d'agir sur votre compte ; les contrats à fort effet de levier amplifient les pertes ; et la limitation de taux (429) ou les coupures réseau peuvent laisser des ordres non remplis ou des annulations échouées. Appliquez des permissions de privilège minimum, liez une liste blanche d'IP, protégez votre SecretKey et Passphrase, et testez minutieusement avec de petites tailles avant de passer en production. Cet article est un guide d'intégration technique et ne constitue pas un conseil en investissement. Si vous souhaitez approfondir, apprenez qu'est-ce qu'une API Futures pour mieux comprendre les spécificités des produits dérivés.