WEEX API Bələdçisi: API Açarından İlk İmzalanmış Əmrə Qədər

Əksər WEEX API inteqrasiyaları strategiya məntiqində uğursuz olmur. Onlar ilk saatda, qarşılaşana qədər aşkar olmayan dörd şeydə uğursuz olur: yeni yaratdığınız açar hələ aktiv deyil, ticarət etmək istədiyiniz cütlük API ağ siyahısında deyil, WebSocket bağlantınız User-Agent başlığı göndərmədiyiniz üçün rədd edilir və göndərdiyiniz dəqiq sətir əvəzinə yenidən seriyalaşdırılmış gövdəni imzaladığınız üçün imzanız bir bayt fərqlidir.

Bu bələdçi WEEX API-ni əvvəldən sona qədər izah edir — açar yaradılması, icazələr, imzalama qaydası, dərəcə limitləri, quruluşları əslində dayandıran səhv kodları və kapital riski olmadan hamısını sınaqdan keçirməyə imkan verən kağız ticarəti son nöqtələri. Aşağıdakı hər şey 21 avqust 2026-cı il tarixinə olan canlı V3 sənədlərinə qarşı yoxlanılıb.

WEEX API nələri əhatə edir: spot, fyuçers və WebSocket

WEEX API iki müstəqil REST domenli iki müstəqil məhsula bölünür. Spot /api/v3 yolu altında api-spot.weex.com-da yerləşir. Fyuçers /capi/v3 yolu altında api-contract.weex.com-da yerləşir. Onlar imzalama sxemini və başlıq dəstini paylaşırlar, lakin başqa heç nəyi yox — ayrı icazə bayraqları, ayrı WebSocket hostları, ayrı əmr parametrləri.

Son nöqtələr iki giriş sinfinə bölünür. İctimai son nöqtələr (server vaxtı, əmr kitabının dərinliyi, kline-lar, maliyyələşdirmə dərəcəsi, 24 saatlıq tikerlər) heç bir autentifikasiyaya ehtiyac duymur, bu da onları imzalamaya toxunmazdan əvvəl şəbəkə yolunuzun işlədiyini təsdiqləmək üçün ən sürətli yol edir. Şəxsi son nöqtələr — balanslar, mövqelər, əmrlər — hər sorğuda tam dörd başlıqlı imza tələb edir.

Tik səviyyəsində hər hansı bir şey üçün, WEEX sizi REST sorğusundan çox WebSocket-ə yönəldir və bu düzgün qərardır: ictimai kanallar tiker, dərinlik və ticarət axınlarını daşıyır, şəxsi kanal isə hesab, mövqe və əmr yeniləmələrini daşıyır. Əmr kitabı yaratmaq üçün REST üzərindən dərinliyi sorğulamaq IP çəki büdcənizi heç bir fayda olmadan yandıracaq.

Miqyas üçün bir köhnə istinad nöqtəsi: 21 avqust 2026-cı il tarixinə, BTC/USDT daimi müqaviləsi WEEX fyuçers kitabında 65,088.8 USDT son qiymətini sitat gətirirdi — /capi/v3/market/ticker24h çağırışınızın qaytardığı eyni tik.

WEEX API açarını necə yaratmaq və icazələri təyin etmək olar

Açarlar veb platformada Hesab → API İdarəetmə bölməsindən yaradılır. Hər hesab 10-a qədər API açar qrupunu saxlaya bilər.

Yaratma üç dəyər qaytarır və üçüncüsü insanların itirdiyidir:

• APIKey — ACCESS-KEY başlığında göndərilən ictimai identifikator.
• SecretKey — HMAC imzalama sirri. Bir dəfə göstərilir.
• Passphrase — istifadəçi tərəfindən müəyyən edilmiş, ACCESS-PASSPHRASE-də göndərilir. Dəyişdirilə bilməz və bərpa edilə bilməz. Onu itirsəniz, açarı yenidən yaradırsınız.

Üç konfiqurasiya detalı digər hər şeyin cəmindən daha çox dəstək biletinə səbəb olur:

1. Yeni açarlar standart olaraq Yalnız oxunur rejimindədir. Ticarət icazəsi ayrıca bir onay qutusudur və məhsula xasdır — spot ticarət üçün Spot, müqavilələr üçün Futures. Birini yoxlamaq digərini aktivləşdirmir. Yalnız oxunur açarında əmr vermək -1052 qaytarır.
2. Açarların qlobal miqyasda yayılması təxminən 15 dəqiqə çəkir. Yaxşı autentifikasiya edən və sonra fərqli bir son nöqtədə uğursuz olan bir açar adətən hələ tam aktiv deyil. İmzanızı sazlamazdan əvvəl gözləyin.
3. Parol ifadəsini alfanumerik saxlayın. WEEX açıq şəkildə xüsusi simvollardan istifadə etməməyi tövsiyə edir. Xüsusi simvollardakı kodlaşdırma uyğunsuzluqları izləmək üçün həqiqətən dəhşətli bir səhv sinfidir.

Yaratma ekranındaykən bir IP ağ siyahısını bağlayın. Bağlanmamış açar internetin istənilən yerindən işləyən bir daşıyıcı etimadnaməsidir və onu saxlayan bir maşın pozulsa, ağ siyahı hücumçu ilə mövqeləriniz arasında dayanan yeganə şeydir.

WEEX spot API vs fyuçers API: vacib fərqlər

Bu, qurarkən açıq saxlamalı olduğunuz cədvəldir. İki məhsul simmetrik görünür, lakin belə deyil.

Bunlardan ikisi ən çox çətinlik yaradır. Fyuçers hər əmrdə newClientOrderId tələb edir, buna görə də onu buraxan spot-əsaslı kod bazası müqavilələrə yönəltdiyiniz anda rədd ediləcək. Və POST_ONLY yalnız fyuçerslərdə mövcuddur — spot API-yə qarşı yazılmış yalnız maker strategiyasının yayılmanı keçməməsini təmin etmək üçün yerli bir yolu yoxdur.

Fyuçers TP/SL parametrləri adətən aldıqlarından daha çox diqqətə layiqdir. Giriş əmrinə tpTriggerPrice və slTriggerPrice əlavə etmək o deməkdir ki, stopunuz mövqe açıldığı andan birjada mövcuddur, prosesin çökməsindən və ya şəbəkə bölgüsündən sağ çıxa bilməyən bir sonrakı çağırışla yerləşdirilməkdənsə. Siz həmçinin TpWorkingType və SlWorkingType vasitəsilə hər ayaq üçün tetik mənbəyini seçə bilərsiniz — stop üçün MARK_PRICE daha təhlükəsiz standartdır, çünki CONTRACT_PRICE qeyri-likvid cütlükdə nazik son ticarət çapı ilə yüksələ bilər.

WEEX API sorğusunu necə düzgün imzalamaq olar

Hər şəxsi çağırış dörd başlıq daşıyır: ACCESS-KEY, ACCESS-SIGN, ACCESS-PASSPHRASE, ACCESS-TIMESTAMP, üstəgəl Content-Type: application/json.

İmzalama qaydası hər iki domendə eynidir. Bu sətri qurun:

timestamp + METHOD + requestPath + "?" + queryString + body

Sorğu parametrləri olmadıqda ? və queryString-i buraxın; heç biri olmadıqda body-ni buraxın. Onu SecretKey ilə HMAC-SHA256 edin, sonra nəticəni Base64 ilə kodlaşdırın.

import base64, hashlib, hmac, json, time, requests

API_KEY, SECRET, PASSPHRASE = "...", "...", "..."
BASE = "https://api-contract.weex.com"
path = "/capi/v3/order"
body = json.dumps({
    "symbol": "BTCUSDT", "side": "BUY", "positionSide": "LONG",
    "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01",
    "price": "60000", "newClientOrderId": "my-order-0001",
}, separators=(",", ":"))

ts = str(int(time.time() * 1000))
message = ts + "POST" + path + body
sign = base64.b64encode(
    hmac.new(SECRET.encode(), message.encode(), hashlib.sha256).digest()
).decode()

r = requests.post(BASE + path, data=body, headers={
    "ACCESS-KEY": API_KEY, "ACCESS-SIGN": sign,
    "ACCESS-PASSPHRASE": PASSPHRASE, "ACCESS-TIMESTAMP": ts,
    "Content-Type": "application/json",
})

json=payload deyil, data=body-yə diqqət yetirin. Göndərdiyiniz dəqiq baytları imzalayın. Əgər HTTP müştəriniz lüğəti yenidən seriyalaşdırırsa — açarları yenidən sıralayırsa və ya ayırıcılardan sonra boşluqlar daxil edirsə — server fərqli bir daycest hesablayır və siz -1047 alırsınız, səbəbin boşluq olduğuna dair heç bir işarə olmadan.

Zaman damğası pəncərəsi WEEX server vaxtına qarşı 30 saniyədir. Əgər host saatınız sürüşürsə, sorğular imzalama səhvi kimi görünən bir şəkildə fasilələrlə uğursuz olmağa başlayır. GET /capi/v3/market/time çağırın və yerli vaxta etibar etməkdənsə ofseti izləyin.

WebSocket şəxsi kanalları fərqli şəkildə imzalayır və bu insanları tutur: mesaj yalnız timestamp + requestPath-dir, burada requestPath /v3/ws/private-dir. Metod yox, gövdə yox.

Kopyalayıb yapışdırmazdan əvvəl bilməyə dəyər bir sənədləşdirmə qəribəliyi: fyuçers İmza səhifəsi qaydanı spot yollardan (/api/v3/order) istifadə edərək təsvir edir. Qayda doğrudur; nümunə yolları fyuçers yolları deyil. Müqavilə domenində olduğunuz zaman /capi/v3/... istifadə edin.

WEEX API dərəcə limitləri: iki vedrə, bir deyil

WEEX iki müstəqil dərəcə limiti sayğacı işlədir və onları qarışdırmaq botların gözləmədikləri 429-ları almasının səbəbidir.

Nəticə etibarilə detal: əmr yerləşdirmə sıfır IP çəkisi istehlak edir, ləğv etmələr və sorğular isə sıfır əmr sayı istehlak edir. Onlar həqiqətən ayrı dəftərlərdir. Aqressiv şəkildə yerləşdirən və ləğv edən bir bazar yaradan döngə, ləğv trafikinin sakitcə IP çəkisini boşaltdığı halda yerləşdirmə zamanı ƏMR vedrəsini tükəndirəcək — və heç bir sayğac sizi digəri haqqında xəbərdar etmir.

Müştəri tərəfində sorğuları saymaqdansa başlıqları oxuyun. X-REMAINING-WEIGHT-1M və X-ORDER-REMAINING-1M hər çağırışda geri qayıdır və serverin baxışını əks etdirir, bu da vacib olan yeganə baxışdır. Limiti aşmaq HTTP 429 qaytarır və 10 saniyəlik qadağanı işə salır, 429 vasitəsilə vurmağa davam etmək API girişinin risk nəzarəti tərəfindən deaktiv edilməsinin ən sürətli yoludur.

Əgər bir qutudan bir neçə strategiya işlədirsinizsə, IP vedrəsinin paylaşıldığını unutmayın. Bir serverdəki iki bot hər 10 saniyədə eyni 500 çəki üçün rəqabət aparır.

Əksər inteqrasiyaları dayandıran WEEX API səhvləri

Səhv cavabları bir kod və mesaj cütüdür. Bunlar istehsalda deyil, inteqrasiya zamanı görünən səhvlərdir:

-1058 xüsusi bir iş axınına layiqdir. Hər WEEX müqaviləsi API ticarəti üçün aktivləşdirilməyib və UI-dən hansının olduğunu anlamağın bir yolu yoxdur. Başlanğıcda GET /capi/v3/market/apiTradingSymbols çağırın, massivi keşləyin və strategiyanız əmr qurmazdan əvvəl simvolları ona qarşı yoxlayın. Bu bir yoxlama iş vaxtı uğursuzluqlarının bütün bir sinfini aradan qaldırır.

Səhv kimi görünən və olmayan daha ikisi. 403 qaytaran bir WebSocket əl sıxma adətən User-Agent başlığını buraxdığınız deməkdir — məzmun ixtiyaridir, lakin firewall onsuz bağlantıları ləğv edir. Və sənədlər hazırda ləğv uğursuzluqları ilə bağlı razılaşmır: səhv kodu istinadı -1054-ü ümumi sistem səhvinə və -3200-ü "əmr mövcud deyil"-ə xəritələyir, fyuçers FAQ isə "əmr mövcud deyil"-i -1054-ə aid edir. Birində budaqlanmaqdansa, ləğv yollarında hər iki kodu idarə edin.

Əvvəlcə WEEX kağız ticarəti son nöqtələrində sınaqdan keçirin

WEEX fyuçers domenində simulyasiya edilmiş ticarət son nöqtələri əlavə etdi və onlar canlı səthi oyuncaq deyil, əsl quru sınaq olacaq qədər yaxından əks etdirir:

• GET /capi/v3/sim/balance — SUSDT ilə ifadə olunan simulyasiya edilmiş balanslar
• GET /capi/v3/sim/position/allPosition — mövqelər, o cümlədən hedcinq-rejim uzun/qısa cütlükləri
• POST /capi/v3/sim/order — adi növlər üzrə əmr yerləşdirmə
• GET /capi/v3/sim/order/history — tarixi simulyasiya edilmiş dolumlar

Eyni domen, eyni başlıqlar, eyni imzalama qaydası. /capi/v3/order-i /capi/v3/sim/order ilə dəyişdirmək tam inteqrasiya testini keçirmək üçün lazım olan yeganə dəyişiklikdir.

Onlardan sisteminizin yalnız real şəraitdə pozulan hissələrini təsdiqləmək üçün istifadə edin: düşmüş WebSocket-dən sonra yenidən qoşulma məntiqi, əmr vəziyyəti maşınınızın REST təsdiqindən əvvəl dolum gəldikdə bərpa olub-olmaması, mövqe ölçülərinizin leverec tavanında düzgün işi görüb-görməməsi. Bunlar istehsalda pula başa gələn uğursuzluqlardır və heç biri üzə çıxmaq üçün canlı kapital tələb etmir.

Onların ətrafında arxitektura qurmazdan əvvəl bilməyə dəyər: WEEX hazırda nə TradingView vebhok icrasını, nə də FIX şlüzünü dəstəkləmir. Əgər strategiyanız hər ikisini nəzərdə tutursa, bunun əvəzinə REST və WebSocket üçün büdcə ayırın.

Nəticə

Spot və fyuçersin imzalama sxemini paylaşan və demək olar ki, başqa heç nəyi paylaşmayan iki məhsul olduğunu daxil etdikdən sonra WEEX API sadədir. Dörd başlığı düzgün alın, göndərdiyiniz dəqiq baytları imzalayın, API ticarət simvolu ağ siyahısını keşləyin, sorğuları saymaqdansa dərəcə limiti başlıqlarını oxuyun və -1047, -1052 və -1058-i açıq şəkildə idarə edin — bu, səhv gedən şeylərin böyük əksəriyyətini əhatə edir.

Ən az vaxt itirən ardıcıllıq: Yalnız oxunur icazəsi ilə bir açar yaradın, ictimai son nöqtənin cavab verdiyini təsdiqləyin, bir imzalanmış şəxsi oxuma işini əldə edin, tam strategiyanızı kağız ticarəti son nöqtələrinə qarşı işlədin və yalnız bundan sonra ticarət icazəsini aktivləşdirin və IP ağ siyahısını bağlayın. Tam son nöqtə istinadları WEEX fyuçers API sənədlərində və WEEX spot API sənədlərində yaşayır, icazə və dərəcə limiti xüsusiyyətləri isə fyuçers API FAQ-da toplanıb.

FAQ

1. Spot və fyuçers üçün ayrı WEEX API açarlarına ehtiyacım varmı?

Xeyr — bir açar hər iki icazəni daşıya bilər. Lakin onlar ayrı onay qutularıdır və hər biri standart olaraq sönülüdür. Yalnız Spot yoxlanılmış bir açar hər fyuçers əmrində -1052 qaytaracaq və əksinə.

2. WEEX API dərəcə limitləri nədir?

İki müstəqil vedrə: ümumi REST son nöqtələri üçün IP başına hər 10 saniyədə 500 çəki və fyuçers üçün hesab başına dəqiqədə 300 əmr yerləşdirmə. WebSocket IP başına 20 eyni vaxtda bağlantı, bağlantı başına 100 kanal ilə məhdudlaşdırılır. Bunlardan hər hansı birini aşmaq HTTP 429 və 10 saniyəlik qadağa qaytarır.

3. Niyə WEEX API açarım yaratdıqdan dərhal sonra -1049 qaytarır?

Yeni və dəyişdirilmiş açarların WEEX sistemləri arasında yayılması təxminən 15 dəqiqə çəkir. Açar təzədirsə, daha çox sazlamadan əvvəl gözləyin. Davam edərsə, parol ifadəsində xüsusi simvolların olub-olmadığını yoxlayın — WEEX yalnız alfanumerik tövsiyə edir.

4. Hər WEEX cütlüyünü API vasitəsilə ticarət edə bilərəmmi?

Xeyr. Yalnız API ticarət ağ siyahısındakı cütlüklər proqramlaşdırılmış şəkildə mövcuddur. Cari siyahı üçün GET /capi/v3/market/apiTradingSymbols çağırın; ondan kənarda olan hər şey -1058 qaytarır.

5. WEEX TradingView xəbərdarlıqlarını və ya FIX-i dəstəkləyirmi?

Heç biri 2026-cı il aprel sənədləşdirmə yeniləməsinə görə dəstəklənmir. Avtomatlaşdırma REST və WebSocket API-ləri vasitəsilə həyata keçirilir.

6. WEEX API strategiyasını vəsaitləri riskə atmadan necə sınaqdan keçirə bilərəm?

/capi/v3/sim/ altındakı fyuçers kağız ticarəti son nöqtələrindən istifadə edin. Onlar canlı son nöqtələrlə eyni autentifikasiya və imzalamanı qəbul edir və simulyasiya edilmiş SUSDT ilə hesablaşırlar.

Risk Xəbərdarlığı

Kripto aktivləri dəyişkəndir və tez bir zamanda dəyər itirə bilər; onlarla ticarət kapitalın qismən və ya tam itirilməsi ilə nəticələnə bilər. API ticarəti bu riski azaltmaqdansa cəmləşdirir. Avtomatlaşdırılmış sistemlər insan bir nasazlığı fərq etməzdən əvvəl yüzlərlə əmr yerləşdirə bilər və imza səhvi, köhnəlmiş qiymət axını və ya idarə olunmayan yenidən qoşulma heç kimin nəzərdə tutmadığı mövqelər aça bilər. Fyuçers ticarəti leverec riski əlavə edir: bəzi WEEX müqavilələrində 400×-ə qədər leverec mövcud olduqda, əks hərəkətlər bir mövqeni saniyələr içində ləğv edə bilər və nazik bazarda stop tetikleyicisi kimi CONTRACT_PRICE istifadə etmək sizi fitil ilə idarə olunan stop-outlara məruz qoyur. API açarları həm də saxlama riskidir — ticarət icazəsi olan bağlanmamış açar internetdəki istənilən IP-dən işləyən canlı etimadnamədir. Bir IP ağ siyahısını bağlayın, inteqrasiyanız kağız ticarəti son nöqtələrinə qarşı sınaqdan keçirilənə qədər ticarət icazəsini söndürün və öz kodunuzun sonda pis davranacağı fərziyyəsi ilə mövqeləri ölçün.