Kompatybilność API WEEX: Co się zmienia przy migracji z innej giełdy

Jeśli napisałeś już kod integracji dla Binance, OKX lub Bitget, jedyną rzeczą, którą naprawdę chcesz wiedzieć o WEEX, jest to: co możesz wykorzystać ponownie, a co musisz napisać od nowa? Zamiast wymieniać punkty końcowe (endpoints), ten artykuł analizuje kompatybilność API WEEX w trzech wymiarach — stylu uwierzytelniania, ujednoliconej warstwie ccxt oraz wersjonowaniu spot/kontraktów — i kończy się listą kontrolną decyzji dotyczących tego, co zmienić podczas migracji. Nacisk położony jest na dwie rzeczy, które w praktyce sprawiają problemy: sposób wywoływania oraz obsługę uprawnień i kluczy.

Główny wniosek: projekt uwierzytelniania WEEX należy do rodziny OKX / Bitget (HMAC pre-sign zakodowany w Base64 plus hasło), a nie do stylu "podpisu ciągu zapytania" (query-string signature) znanego z Binance. Zrozum ten jeden fakt, a będziesz mógł dokładnie oszacować wysiłek związany z migracją.

Do czego właściwie odnosi się "Kompatybilność API WEEX"

"Kompatybilność" ma tutaj trzy warstwy — nie myl ich:

• Kompatybilność uwierzytelniania — czy algorytm podpisywania, nagłówki i format znacznika czasu (timestamp) pasują do giełdy, którą znasz, co decyduje o tym, czy Twój moduł podpisywania wymaga przepisania.
• Kompatybilność abstrakcji — czy ujednolicona biblioteka, taka jak ccxt, pozwala na uruchomienie jednej bazy kodu na różnych platformach.
• Kompatybilność wersji wewnętrznych — czy spot i kontrakty WEEX oraz wersje V2 i V3 współdzielą pola i ścieżki, co decyduje o Twoim wysiłku przy przechodzeniu między produktami wewnątrz WEEX.

Ustal, którą warstwę migrujesz, a następnie przeczytaj poniższe porównania.

Kompatybilność uwierzytelniania: Styl WEEX vs Binance vs OKX

To najtrudniejsza część każdej migracji. Zgodnie z dokumentacją podpisu, WEEX tworzy ciąg pre-sign w formacie timestamp + method + path + body, wykonuje HMAC SHA256, koduje wynik w Base64 i przekazuje go przez cztery nagłówki ACCESS-*. Tabela przedstawia trzy główne style obok siebie (dane WEEX z oficjalnej dokumentacji, stan na lipiec 2026; pozostałe to powszechnie udokumentowane konwencje publiczne każdej giełdy):

Wniosek: migrując z OKX lub Bitget do WEEX, logika podpisywania to niemal kopiuj-wklej — głównie zmieniasz nazwy nagłówków. Migracja z Binance oznacza przepisanie modułu podpisywania — Binance podpisuje parametry zapytania, generuje wynik w formacie hex i nie używa hasła, co jest modelem całkowicie różnym od pre-sign w Base64 w WEEX. Tymczasem WEEX używający znacznika czasu w milisekundach jest bliższy Binance niż formatowi ISO w OKX, a tego typu szczegóły najłatwiej przeoczyć podczas migracji.

Czy ccxt może sprawić, że WEEX będzie kompatybilny "z pudełka"?

Tak — i jest to najmniej bolesny sposób na obejście różnic w uwierzytelnianiu. Biblioteka open-source ccxt zawiera już WEEX, obejmując spot, kontrakty (swap) i WebSocket w ponad 80 ujednoliconych metodach. Jeśli już używasz ccxt z inną platformą, przejście na WEEX to w zasadzie zmiana nazwy klasy i trzech pól poświadczeń:

import ccxt

ex = ccxt.weex({
    "apiKey": "twój-APIKey",
    "secret": "twój-SecretKey",
    "password": "twoje-Hasło",   # Hasło WEEX → "password" w ccxt
})
print(ex.fetch_ticker("BTC/USDT"))

fetch_ticker, fetch_balance i create_order są identyczne na różnych platformach, więc warstwa biznesowa prawie się nie zmienia. Zastrzeżenie jest takie, że ccxt to abstrakcja społecznościowa: nazewnictwo symboli (BTC/USDT vs BTCUSDT), precyzja i pola opłat są normalizowane przez ccxt, ale jeśli WEEX wprowadzi nowy punkt końcowy, pokrycie ccxt może być opóźnione — weryfikuj to z wprowadzeniem do API WEEX, gdy szukasz nowych funkcji.

Kompatybilność wersji Spot i Kontraktów (V2 / V3 BETA)

Istnieje również kwestia kompatybilności wewnątrz WEEX, gdy przechodzisz między produktami. API spot i kontraktów działają w wersji V3 (BETA), przy czym kontrakty zachowują również V2. Wynikają z tego dwa wnioski:

• Spot i kontrakty współdzielą to samo uwierzytelnianie ACCESS-* oraz podpisywanie HMAC SHA256 + Base64, więc moduł uwierzytelniania jest wielokrotnego użytku w obu liniach produktów — różnią się tylko ścieżki i pola biznesowe.
• Kontrakty działające w V2 obok V3 oznaczają, że starszy kod może znajdować się na V2. Ponieważ V3 jest nadal oznaczona jako BETA, potwierdź wersję, od której zależą Twoje systemy przed uruchomieniem produkcyjnym i zasubskrybuj dziennik zmian, aby zmieniające się pole BETA Cię nie zaskoczyło.

W skrócie: wewnętrzna kompatybilność uwierzytelniania WEEX jest silna; musisz jedynie uważać na status "BETA" i tempo migracji wersji.

Jaki kod zmieniasz migrując do WEEX

Rozbity na listę kontrolną, wysiłek różni się znacząco w zależności od źródła:

Niezależnie od źródła, należy przestrzegać trzech ustawień specyficznych dla WEEX: znacznik czasu różniący się o ponad 30 sekund od serwera jest odrzucany; publiczne punkty końcowe pozwalają na około 20 zapytań na 2 sekundy i zwracają HTTP 429 w przypadku przekroczenia; ogólne zasady znajdują się w dokumencie standardowych specyfikacji.

Czy warstwa kompatybilności jest bezpieczna? Uwagi dotyczące migracji uprawnień i kluczy

Rzeczą najczęściej "zapomnianą" podczas migracji między giełdami jest konfiguracja bezpieczeństwa — luźne nawyki z starej platformy stają się zagrożeniem w momencie, gdy trafiają na nowy klucz. To, czy WEEX obsługuje handel przez API, oraz oficjalne wytyczne bezpieczeństwa, są opisane w wyjaśnieniu handlu przez API WEEX. Podczas migracji zweryfikuj:

• Zminimalizuj uprawnienia — klucze WEEX domyślnie mają status Read Only, a dostęp do handlu jest ręczny; nie otwieraj wszystkiego dla wygody i nie przenoś nawyku "pełnego dostępu" z starej giełdy.
• Ponownie powiąż białą listę IP — po zmianie IP wyjściowych serwera, powiąż je ponownie; WEEX wyraźnie oznacza klucze bez powiązania IP jako ryzykowne.
• Hasło (passphrase) to nowe pole — zespoły migrujące z Binance rutynowo zapominają, że WEEX wymaga hasła, którego nie można odzyskać w przypadku utraty; uwzględnij to w swoim przepływie sekretów.
• Brak uprawnień do wypłat domyślnie — ogranicza to szkody w przypadku kradzieży klucza, ale nie jest powodem do rozluźnienia obsługi SecretKey.

Podsumowanie

Kompatybilność API WEEX sprowadza się do jednego zdania: uwierzytelnianie należy do rodziny OKX / Bitget, ccxt pokrywa różnice, a spot i kontrakty współdzielą wewnętrzny schemat podpisywania. Migracja z ccxt lub giełdy z tej samej rodziny jest prawie bezbolesna; z Binance to głównie przepisanie podpisywania plus dodanie hasła. Prawdziwą dodatkową inwestycją nie jest integracja, lecz ponowne wykonanie konfiguracji bezpieczeństwa (zasada najmniejszych uprawnień, biała lista IP, zarządzanie hasłem) w nowym środowisku. Aby rozpocząć porównanie w praktyce, pracuj w oparciu o wprowadzenie do API WEEX.

Dalsza lektura: pokrycie metod WEEX przez ccxt znajduje się w jego oficjalnym wiki.

FAQ

1. Czy API WEEX jest kompatybilne z API Binance?

Nie na poziomie podpisywania. Binance podpisuje ciąg zapytania, generuje hex i nie używa hasła; WEEX podpisuje timestamp + method + path + body, generuje Base64 po HMAC SHA256 i wymaga hasła. Migracja z Binance oznacza przepisanie modułu podpisywania.

2. Czy API WEEX jest kompatybilne z OKX lub Bitget?

Bardzo blisko. Wszystkie trzy używają stylu pre-sign Base64 + hasło z nagłówkami ACCESS-*, więc logika podpisywania jest w dużej mierze wielokrotnego użytku. Główna różnica polega na tym, że OKX używa znacznika czasu ISO-8601, podczas gdy WEEX używa epoki w milisekundach.

3. Czy ccxt może łączyć się z WEEX i innymi giełdami jednocześnie?

Tak. ccxt zawiera już WEEX (spot, kontrakty, WebSocket), a te same metody fetch_ticker, create_order i podobne działają na różnych platformach — zmiana giełdy zmienia tylko instancję klasy i poświadczenia.

4. Czy spot i kontrakty WEEX mogą współdzielić jedną bazę kodu uwierzytelniania?

Tak. Obie linie produktów używają tych samych nagłówków ACCESS-* i podpisywania HMAC SHA256 + Base64, więc moduł uwierzytelniania jest wielokrotnego użytku; różnią się tylko ścieżki żądań i pola biznesowe. Obie są w wersji V3 (BETA), przy czym kontrakty są również w V2.

5. Jaki element bezpieczeństwa jest najczęściej pomijany przy migracji do WEEX?

Trzy: brak ponownego powiązania białej listy IP; pominięcie hasła przy przejściu z giełdy bez hasła, takiej jak Binance; oraz przeniesienie klucza z "pełnym dostępem". Klucze WEEX domyślnie mają status tylko do odczytu bez uprawnień do wypłat, więc odpowiednio dostosuj uprawnienia do zasady najmniejszych przywilejów.

Ostrzeżenie o ryzyku

Aktywa cyfrowe są wysoce zmienne, a zautomatyzowany handel lub handel międzygiełdowy przez API może skutkować utratą części lub całości kapitału z powodu błędów strategii, gwałtownych ruchów rynkowych lub awarii systemu. Migracja i konfiguracje wieloplatformowe dodają specyficzne ryzyka: błędna konfiguracja podpisu lub znacznika czasu może spowodować nieudane lub zduplikowane zlecenia; wyciek klucza bez powiązania IP może pozwolić atakującemu na działanie na Twoim koncie; poleganie na zewnętrznej abstrakcji, takiej jak ccxt, oznacza, że jej mapowanie pól lub opóźnienia wersji mogą odbiegać od rzeczywistego zachowania giełdy; a dźwignia kontraktowa potęguje straty. Stosuj uprawnienia najmniejszych przywilejów, rekonfiguruj białą listę IP i hasło dla każdej giełdy oraz sprawdzaj kompatybilność na małych kwotach przed produkcją. Ten artykuł jest porównaniem technicznym i nie stanowi porady inwestycyjnej.