Kompatibilitas API WEEX: Apa yang Berubah Saat Anda Bermigrasi Dari Exchange Lain

Jika Anda sudah menulis kode integrasi untuk Binance, OKX, atau Bitget, satu-satunya hal yang benar-benar ingin Anda ketahui tentang WEEX adalah ini: apa yang bisa Anda gunakan kembali, dan apa yang harus Anda tulis ulang? Daripada sekadar mencantumkan endpoint, artikel ini melihat kompatibilitas API WEEX melalui tiga sumbu — gaya autentikasi, lapisan terpadu ccxt, dan pembuatan versi spot/kontrak — serta diakhiri dengan daftar periksa keputusan tentang apa yang harus diubah saat Anda bermigrasi. Fokusnya tetap pada dua hal yang sering rusak dalam praktiknya: bagaimana Anda memanggilnya, dan bagaimana Anda menangani izin serta kunci.

Inti utamanya: desain autentikasi WEEX termasuk dalam keluarga OKX / Bitget (HMAC pre-sign yang dienkode Base64 ditambah passphrase), bukan gaya "tanda tangan query-string" Binance. Pahami satu fakta itu dan Anda dapat memperkirakan upaya migrasi dengan akurat.

Apa yang Sebenarnya Dimaksud dengan "Kompatibilitas API WEEX"

"Kompatibilitas" di sini memiliki tiga lapisan — jangan mencampuradukkannya:

• Kompatibilitas Auth — apakah algoritma penandatanganan, header, dan format timestamp cocok dengan exchange yang Anda kenal, yang menentukan apakah modul penandatanganan Anda perlu ditulis ulang.
• Kompatibilitas Abstraksi — apakah pustaka terpadu seperti ccxt memungkinkan satu basis kode berjalan di berbagai tempat.
• Kompatibilitas Versi Internal — apakah spot vs kontrak WEEX, dan V2 vs V3, berbagi field dan jalur, yang menentukan upaya Anda saat melintasi produk di dalam WEEX.

Cari tahu lapisan mana yang Anda migrasikan, lalu baca perbandingan di bawah ini.

Kompatibilitas Auth: Gaya WEEX vs Binance vs OKX

Ini adalah bagian tersulit dari migrasi apa pun. Sesuai dengan dokumen tanda tangannya, WEEX membangun string pre-sign dari timestamp + method + path + body, menjalankan HMAC SHA256, mengenkode output ke Base64, dan meneruskannya melalui empat header ACCESS-*. Tabel ini menyandingkan tiga gaya utama (data WEEX dari dokumen resmi, per Juli 2026; yang lainnya adalah konvensi publik yang didokumentasikan secara luas dari masing-masing exchange):

Intinya: bermigrasi dari OKX atau Bitget ke WEEX, logika penandatanganan hampir bisa copy-paste — Anda hanya perlu mengganti nama header. Bermigrasi dari Binance berarti menulis ulang modul penandatanganan — Binance menandatangani parameter query, menghasilkan hex, dan tidak memiliki passphrase, model yang sama sekali berbeda dari pre-sign Base64 WEEX. Sementara itu, WEEX yang menggunakan timestamp milidetik lebih dekat ke Binance daripada format ISO OKX, dan detail semacam itu adalah hal termudah untuk dilewatkan dalam migrasi.

Bisakah ccxt Membuat WEEX Kompatibel Secara Langsung?

Ya — dan itu adalah cara yang paling tidak menyakitkan untuk menghindari perbedaan auth. Pustaka sumber terbuka ccxt sudah menyertakan WEEX, mencakup spot, kontrak (swap), dan WebSocket di lebih dari 80 metode terpadu. Jika Anda sudah menjalankan ccxt terhadap tempat lain, pindah ke WEEX pada dasarnya hanya masalah nama kelas dan tiga field kredensial:

import ccxt

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

fetch_ticker, fetch_balance, dan create_order identik di seluruh tempat, jadi lapisan bisnis hampir tidak berubah. Peringatannya adalah bahwa ccxt adalah abstraksi komunitas: penamaan simbol (BTC/USDT vs BTCUSDT), presisi, dan field biaya dinormalisasi oleh ccxt, tetapi jika WEEX merilis endpoint baru, cakupan ccxt bisa tertinggal — verifikasi terhadap pengantar API WEEX saat mengejar fitur baru.

Kompatibilitas Versi Spot dan Kontrak (V2 / V3 BETA)

Ada pertanyaan kompatibilitas di dalam WEEX juga, saat Anda melintasi produk. API spot dan kontrak keduanya ada di V3 (BETA), dengan kontrak juga tetap menggunakan V2. Dua kesimpulan mengikuti:

• Spot dan kontrak berbagi auth ACCESS-* dan penandatanganan HMAC SHA256 + Base64 yang sama, jadi modul auth dapat digunakan kembali di kedua lini produk — hanya jalur dan field bisnis yang berbeda.
• Kontrak yang menjalankan V2 bersama V3 berarti kode lama mungkin berada di V2. Karena V3 masih diberi label BETA, konfirmasikan versi yang Anda andalkan sebelum peluncuran produksi dan berlangganan changelog agar field BETA yang berubah tidak mengejutkan Anda.

Singkatnya: kompatibilitas auth internal WEEX kuat; yang perlu Anda perhatikan adalah status "BETA" dan irama migrasi versi.

Kode Apa yang Anda Ubah Saat Bermigrasi ke WEEX

Dipecah menjadi daftar periksa yang dapat ditindaklanjuti, upaya bervariasi tajam berdasarkan sumber:

Apa pun sumbernya, tiga pengaturan khusus WEEX harus dihormati: timestamp yang lebih dari 30 detik dari server akan ditolak; endpoint publik mengizinkan sekitar 20 permintaan per 2 detik dan mengembalikan HTTP 429 jika berlebih; aturan umum ada di dokumen spesifikasi standar.

Apakah Lapisan Kompatibilitas Aman? Catatan Migrasi Izin dan Kunci

Hal yang paling sering "dilupakan" dalam migrasi lintas exchange adalah konfigurasi keamanan — kebiasaan longgar dari tempat lama menjadi kewajiban saat mereka mendarat di kunci baru. Apakah WEEX mendukung trading API, dan panduan keamanan resminya, tercakup dalam penjelasan trading API WEEX. Selama migrasi, verifikasi:

• Minimalkan kembali izin — kunci WEEX default ke Read Only, dan akses perdagangan bersifat manual; jangan buka semuanya demi kenyamanan, dan jangan bawa kebiasaan "akses penuh" dari tempat lama.
• Ikat kembali whitelist IP — setelah mengganti IP egress server, ikat kembali; WEEX secara eksplisit menandai kunci tanpa ikatan IP sebagai risiko.
• Passphrase adalah field baru — tim yang bermigrasi dari Binance secara rutin lupa bahwa WEEX memerlukan passphrase yang tidak dapat dipulihkan jika hilang; masukkan ke dalam alur rahasia Anda.
• Tidak ada izin penarikan secara default — ini membatasi kerusakan kunci yang dicuri, tetapi bukan alasan untuk melonggarkan penanganan SecretKey.

Intinya

Kompatibilitas API WEEX bermuara pada satu kalimat: auth termasuk dalam keluarga OKX / Bitget, ccxt menutupi perbedaannya, dan spot serta kontrak berbagi satu skema penandatanganan secara internal. Bermigrasi dari ccxt atau exchange keluarga yang sama hampir tidak menyakitkan; dari Binance, ini terutama penulisan ulang penandatanganan ditambah menambahkan passphrase. Investasi tambahan yang sebenarnya bukanlah integrasi — melainkan mengerjakan ulang konfigurasi keamanan (hak istimewa paling sedikit, whitelist IP, manajemen passphrase) di lingkungan baru. Untuk memulai perbandingan secara langsung, kerjakan dari pengantar API WEEX.

Bacaan lebih lanjut: cakupan metode WEEX ccxt ada di wiki resmi.

FAQ

1. Apakah API WEEX kompatibel dengan API Binance?

Tidak pada tingkat penandatanganan. Binance menandatangani string query, menghasilkan hex, dan tidak menggunakan passphrase; WEEX melakukan pre-sign timestamp + method + path + body, menghasilkan Base64 setelah HMAC SHA256, dan memerlukan passphrase. Bermigrasi dari Binance berarti menulis ulang modul penandatanganan.

2. Apakah API WEEX kompatibel dengan OKX atau Bitget?

Sangat dekat. Ketiganya menggunakan gaya pre-sign Base64 + passphrase dengan header ACCESS-*, jadi logika penandatanganan sebagian besar dapat digunakan kembali. Perbedaan utamanya adalah OKX menggunakan timestamp ISO-8601 sementara WEEX menggunakan epoch milidetik.

3. Bisakah ccxt terhubung ke WEEX dan exchange lain sekaligus?

Ya. ccxt sudah menyertakan WEEX (spot, kontrak, WebSocket), dan metode fetch_ticker, create_order, dan sejenisnya yang sama berfungsi di seluruh tempat — beralih exchange hanya mengubah kelas yang diinstansiasi dan kredensial.

4. Bisakah spot dan kontrak WEEX berbagi satu basis kode auth?

Ya. Kedua lini produk menggunakan header ACCESS-* dan penandatanganan HMAC SHA256 + Base64 yang sama, jadi modul auth dapat digunakan kembali; hanya jalur permintaan dan field bisnis yang berbeda. Keduanya ada di V3 (BETA), dengan kontrak juga di V2.

5. Item keamanan apa yang paling sering terlewatkan saat bermigrasi ke WEEX?

Tiga: gagal mengikat kembali whitelist IP; melewatkan passphrase saat datang dari tempat tanpa passphrase seperti Binance; dan membawa kunci "akses penuh". Kunci WEEX default ke read-only tanpa izin penarikan, jadi sesuaikan kembali ke hak istimewa paling sedikit.

Peringatan Risiko

Aset digital sangat fluktuatif, dan perdagangan otomatis atau lintas exchange melalui API dapat kehilangan sebagian atau seluruh modal Anda melalui kelemahan strategi, pergerakan pasar yang tajam, atau kegagalan sistem. Migrasi dan pengaturan multi-tempat menambah risiko khusus: konfigurasi penandatanganan atau timestamp yang salah dapat menyebabkan pesanan gagal atau duplikat; kunci yang bocor tanpa ikatan IP dapat membiarkan penyerang bertindak di akun Anda; mengandalkan abstraksi pihak ketiga seperti ccxt berarti pemetaan field atau jeda versinya mungkin menyimpang dari perilaku aktual exchange; dan leverage kontrak memperkuat kerugian. Terapkan izin hak istimewa paling sedikit, konfigurasi ulang whitelist IP dan passphrase per tempat, dan validasi kompatibilitas dengan ukuran kecil sebelum produksi. Artikel ini adalah perbandingan teknis dan bukan saran investasi.