SDK Python dla API WEEX: Jak podpisywać i wywoływać żądania od początku do końca

Pierwsza rzecz do ustalenia, zanim przejdziemy do kodu: na lipiec 2026 r. WEEX nie oferuje oficjalnego, samodzielnego pakietu o nazwie "weex-python-sdk". Masz w rzeczywistości dwie ścieżki: wywoływanie endpointów REST bezpośrednio za pomocą requests przy użyciu własnych reguł podpisywania WEEX lub korzystanie z biblioteki open-source multi-exchange ccxt, która już obsługuje WEEX. Ten przewodnik przeprowadzi Cię przez obie ścieżki i poświęci większość uwagi dwóm miejscom, w których integracje najczęściej zawodzą: jak podpisać żądanie i jak bezpiecznie przechowywać klucze.

To jest notatka techniczna, którą możesz wkleić do projektu, a nie słownik endpointów. API spot i kontraktów WEEX znajduje się obecnie w wersji V3 (BETA), z V2 nadal dostępną dla kontraktów; poniższy kod używa spot V3.

Co tak naprawdę oznacza "SDK Python dla API WEEX"

Ściśle mówiąc, nie jest to oficjalnie wspierany pakiet — to skrót myślowy oznaczający "klienta Python, który komunikuje się z endpointami WEEX". WEEX udostępnia interfejsy REST i WebSocket obejmujące spot, kontrakty, copy trading i produkty brokerskie. Każdy język, który potrafi wysłać żądanie HTTP i obliczyć podpis HMAC, może się zintegrować.

W praktyce "SDK Python" przybiera trzy formy:

• Lekki wrapper napisany ręcznie — requests plus hmac, kilkadziesiąt linii kodu, minimalne zależności, maksymalna kontrola.
• Ujednolicona biblioteka ccxt — pip install ccxt, traktuj WEEX jako jedną z ponad 100 giełd obsługiwanych przez ccxt, z nazwami metod wspólnymi dla różnych platform.
• Klient WebSocket — websocket-client do subskrypcji danych rynkowych na żywo lub kanałów prywatnych.

Sama wprowadzenie do API instruuje programistów, aby dostosowali się do udokumentowanych schematów i utrzymywali wersjonowanych klientów — innymi słowy, sam składasz SDK; nie czekasz na oficjalne.

Przygotowanie: Utwórz klucz API i określ jego uprawnienia

Przed wykonaniem jakiegokolwiek wywołania, utwórz klucz API na swoim koncie. Zgodnie z dokumentacją przygotowania do integracji, konto może posiadać do 10 grup kluczy. Każdy klucz daje Ci trzy poświadczenia, żadne z nich nie jest opcjonalne:

Uprawnienia mają tu znaczenie: nowo utworzony klucz domyślnie ma status Read Only (tylko do odczytu) — musisz ręcznie włączyć trading spot, aby składać zlecenia. Powiąż białą listę IP w momencie tworzenia; dokumentacja wyraźnie stwierdza, że klucze bez ograniczeń i bez powiązania IP stanowią ryzyko bezpieczeństwa.

Jak wywoływać: Podpisywanie żądania w Pythonie

Reguła podpisywania WEEX, pochodząca z dokumentacji podpisywania, łączy timestamp + metoda (wielkie litery) + ścieżka żądania (z parametrami) + treść, uruchamia HMAC SHA256 z Twoim SecretKey, a następnie koduje wynik w Base64. Timestamp jest w milisekundach, a każde żądanie różniące się o więcej niż 30 sekund od zegara serwera jest odrzucane.

To działa od razu (używając endpointu głębokości z dokumentacji):

import time, hmac, hashlib, base64, requests

API_KEY    = "twoj-APIKey"
SECRET_KEY = "twoj-SecretKey"
PASSPHRASE = "twoj-Passphrase"
BASE = "https://api-spot.weex.com"  # potwierdź host z oficjalnym dokumentem 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()

# Publiczne dane rynkowe nie wymagają podpisu; to pokazuje wzorzec podpisanego nagłówka
print(request("GET", "/api/v3/market/depth?symbol=BTCUSDT&limit=20"))

Pułapka: parametry GET trafiają do zapytania wewnątrz path, POST używa treści JSON, a treść, którą podpisujesz, musi być identyczna bajt w bajt z treścią, którą wysyłasz. Inna kolejność kluczy lub dodatkowa spacja psuje podpis — to najczęstsze źródło błędów 401 w ręcznie pisanych klientach.

Użyj ccxt dla szybkiego startu (najlepszy wybór dla większości)

Jeśli wolisz nie zajmować się podpisywaniem ręcznie, ccxt już obsługuje spot, kontrakty (swap) i WebSocket WEEX za pomocą ponad 80 metod. Kilka linii kodu pozwala uzyskać tickery i zlecenia:

import ccxt   # pip install ccxt

ex = ccxt.weex({
    "apiKey": "twoj-APIKey",
    "secret": "twoj-SecretKey",
    "password": "twoj-Passphrase",   # Passphrase WEEX mapuje się na "password" w ccxt
})

print(ex.fetch_ticker("BTC/USDT"))            # dane rynkowe
# print(ex.fetch_balance())                    # wymaga uprawnień do tradingu
# ex.create_order("BTC/USDT", "limit", "buy", 0.001, 30000)

Zysk: ten sam kod, który dziś wywołuje WEEX, jutro może wywołać inną platformę dzięki zmianie klasy w jednej linii. Kosztem jest to, że ccxt to abstrakcja utrzymywana przez społeczność; obsługa nowego endpointu WEEX może być opóźniona, więc weryfikuj pola z oficjalną dokumentacją, gdy korzystasz z nowych funkcji.

Dane na żywo: Połącz się z WebSocket z Pythona

Polling REST szybko osiągnie limity zapytań. Do danych w czasie rzeczywistym użyj WebSocket; kanał publiczny to wss://ws-spot.weex.com/v3/ws/public, a prywatny to .../private, ten drugi uwierzytelniony tymi samymi czterema polami ACCESS-KEY / ACCESS-SIGN / ACCESS-TIMESTAMP / ACCESS-PASSPHRASE (ciąg podpisu to 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())

Serwer wysyła okresowe wiadomości ping; klient musi odpowiedzieć {"method":"PONG","id":1}, w przeciwnym razie połączenie zostanie zerwane. Szczegóły pól znajdują się w dokumentacji WebSocket.

Czy to bezpieczne? Uprawnienia i higiena kluczy w praktyce

Trading przez API jest tak bezpieczny, jak Twoje zarządzanie kluczami, a nie sam endpoint. Prawie każda strata wynika z niewłaściwego obchodzenia się z kluczami, a nie z naruszenia interfejsu. Praktyczna lista kontrolna:

• Minimalne uprawnienia — włączaj tylko to, czego potrzebuje obecna strategia. Klucz tylko do odczytu nigdy nie uzyska dostępu do tradingu; klucze WEEX domyślnie nie mają też uprawnień do wypłat, co ogranicza to, co może zrobić skradziony klucz.
• Powiąż białą listę IP — zablokuj klucz do IP wyjściowego swojego serwera, aby wyciekły klucz był bezużyteczny gdzie indziej.
• Trzymaj klucze poza kodem — używaj zmiennych środowiskowych lub menedżera sekretów; nigdy nie wpisuj ich na sztywno, nie commituj do Gita i nie wysyłaj w kodzie po stronie klienta.
• Oddziel dewelopment od produkcji — dwa zestawy kluczy, brak zanieczyszczeń krzyżowych, łatwiejsze triage incydentów.
• Planowana rotacja — zmieniaj klucze i ustaw alerty na błędy podpisu oraz błędy 429.

Projektuj pod kątem limitów zapytań od samego początku: publiczne endpointy rynkowe pozwalają na około 20 zapytań na 2 sekundy, a przekroczenie tego zwraca HTTP 429; prywatne endpointy mają własne zasady dla klucza. Wbudowanie mechanizmów ponawiania i backoff w klienta jest lepsze niż późniejsze gaszenie pożarów.

Szybka referencja

Podsumowanie

Nie istnieje oficjalne, samodzielne SDK Python dla API WEEX i nie jest to przeszkodą: logika podpisywania jest czysta (HMAC SHA256 + Base64), a ccxt daje gotowy, ujednolicony punkt wejścia. O wyniku decyduje zarządzanie uprawnieniami i kluczami (domyślnie tylko do odczytu, powiązanie IP, trzymanie sekretów poza repozytorium) — dzięki temu integracja API WEEX w Pythonie jest szybka i stabilna. Gdy będziesz gotowy, utwórz swój pierwszy klucz z dokumentacji przygotowania do integracji.

Dalsza lektura: obsługa WEEX w ccxt jest udokumentowana w jej oficjalnym wiki.

FAQ

1. Czy WEEX ma oficjalne SDK Python?

Nie na lipiec 2026. WEEX udostępnia interfejsy REST i WebSocket; po stronie Pythona piszesz wrapper requests lub używasz ccxt, który już obsługuje WEEX.

2. Moje wywołania ciągle zwracają błąd podpisu (401) — jak to debugować?

Zazwyczaj jedna z trzech rzeczy: timestamp nie jest w milisekundach lub różni się o więcej niż 30s od serwera; kolejność ciągu podpisu jest zła (musi być timestamp + metoda + ścieżka + treść); lub podpisana treść różni się od treści faktycznie wysłanej w POST. Sprawdź każdą z nich.

3. Gdzie w ccxt wpisać passphrase WEEX?

W polu password. ccxt używa apiKey, secret i password, aby mapować na APIKey, SecretKey i Passphrase WEEX.

4. Czy publiczne endpointy rynkowe wymagają podpisu?

Publiczne endpointy, takie jak dane rynkowe, zazwyczaj nie wymagają podpisu; tylko prywatne endpointy dotyczące Twojego konta lub zleceń wymagają pełnego zestawu czterech nagłówków autoryzacji. Publiczne endpointy nadal mają limity zapytań.

5. Dlaczego mój nowy klucz API nie może składać zleceń?

Ponieważ nowy klucz domyślnie ma status Read Only. Ręcznie włącz uprawnienie do tradingu spot podczas tworzenia lub edycji klucza i jednocześnie powiąż białą listę IP.

Ostrzeżenie o ryzyku

Aktywa cyfrowe są wysoce zmienne, a zautomatyzowany trading może prowadzić do utraty części lub całości kapitału z powodu błędów strategii, wahań rynku lub awarii systemu. Trading przez API dodaje specyficzne ryzyka: wyciekły klucz bez powiązania IP może pozwolić atakującemu na działanie na Twoim koncie; kontrakty z wysoką dźwignią amplifikują straty; a limity zapytań (429) lub przerwy w sieci mogą pozostawić zlecenia niezrealizowane lub anulowania nieudane. Stosuj zasadę minimalnych uprawnień, powiąż białą listę IP, chroń swój SecretKey i Passphrase oraz przetestuj dokładnie na małych kwotach przed przejściem na produkcję. Ten artykuł jest technicznym przewodnikiem integracji i nie stanowi porady inwestycyjnej.