Informasi kemitraan: Artikel ini berisi OKX tautan mitra. Jika Anda mendaftar atau melakukan transaksi melalui tautan tersebut, operator dapat memperoleh pendapatan. Manfaat bagi pengguna dapat berbeda menurut akun, wilayah, tingkat VIP, dan kampanye, jadi periksa ketentuan yang benar-benar berlaku pada halaman pendaftaran dan My Rewards.
Jawaban singkat: Pisahkan layanan Public, Private, Business serta lingkungan riil dan Demo OKX WebSocket. Autentikasi kanal yang memerlukan login dengan tanda tangan yang benar. Reset timer N < 30 detik pada setiap respons; setelah N detik tanpa pesan, kirim string ping dan periksa balasan pong. Pantau terpisah total 480 operasi login·subscribe·unsubscribe per koneksi per jam serta 30 koneksi per subakun dan kanal privat yang ditentukan.
Risiko API dan perdagangan: Jangan simpan Secret Key dan Passphrase dalam kode, log, tangkapan layar, atau repositori publik. Keberhasilan koneksi WebSocket tidak menjamin keuntungan atau eksekusi strategi order. Selama koneksi ulang, dapat terjadi order duplikat, status posisi yang sudah kedaluwarsa, peningkatan leverage, dan likuidasi. Karena itu, hentikan order otomatis hingga sinkronisasi status selesai dan lakukan verifikasi terlebih dahulu di lingkungan Demo.
Tabel ringkas batas utama OKX WebSocket
| Item | Ketentuan dan hal yang perlu diperiksa |
|---|---|
| Permintaan koneksi baru | Batas resmi: 3 kali per detik berdasarkan IP Implikasi operasional: Terapkan jeda mundur dan penundaan acak agar semua proses tidak tersambung ulang secara bersamaan saat terjadi gangguan. |
| login·subscribe·unsubscribe | Batas resmi: Total 480 kali per jam untuk setiap koneksi Implikasi operasional: Jika langganan yang sama dikirim berulang kali dalam putaran koneksi ulang, batas akan cepat terpakai. |
| Koneksi tanpa respons | Batas resmi: Koneksi dapat ditutup secara otomatis jika tidak ada langganan atau data selama lebih dari 30 detik Implikasi operasional: Periksa dengan pengatur waktu N detik yang lebih singkat dari 30 detik ping·pong Memeriksa. |
| Koneksi kanal Private tertentu | Batas resmi: 30 koneksi per sub-akun dan kanal Implikasi operasional: Kelola agar beberapa proses tidak berlangganan kanal yang dibatasi secara duplikat, seperti Orders·Account·Positions. |
| Beberapa langganan sekaligus | Batas resmi: Panjang total argumen beberapa kanal tidak lebih dari 64KB Implikasi operasional: Jangan masukkan daftar langganan tanpa batas ke dalam satu pesan; lacak respons konfirmasi dan item yang gagal. |
Angka-angka di atas memiliki cakupan yang berbeda. 3 kali per detik adalah permintaan koneksi berdasarkan IP, 480 kali per jam adalah total operasi login·subscribe·unsubscribe dalam satu koneksi, sedangkan 30 adalah jumlah koneksi aktif untuk setiap kanal tertentu yang dibatasi. Jangan salah mengartikan satu angka sebagai batas keseluruhan lalu lintas WebSocket. Pengiriman order juga dikenai batas kecepatan tersendiri untuk setiap API order.
Pemilihan layanan Public·Private·Business dan lingkungan
| Lingkungan | Ketentuan dan hal yang perlu diperiksa |
|---|---|
| Perdagangan riil | Layanan: Public Contoh endpoint global resmi: wss://ws.okx.com/ws/v5/publicAutentikasi: Data publik seperti harga pasar dan kuotasi tidak memerlukan login |
| Perdagangan riil | Layanan: Private Contoh endpoint global resmi: wss://ws.okx.com/ws/v5/privateAutentikasi: Kanal akun·order·posisi memerlukan login |
| Perdagangan riil | Layanan: Business Contoh endpoint global resmi: wss://ws.okx.com/ws/v5/businessAutentikasi: Periksa spesifikasi terbaru untuk kanal yang digunakan |
| Demo | Layanan: Public Contoh endpoint global resmi: wss://wspap.okx.com/ws/v5/publicAutentikasi: Pisahkan lingkungan dan kunci Demo dari perdagangan riil |
| Demo | Layanan: Private Contoh endpoint global resmi: wss://wspap.okx.com/ws/v5/privateAutentikasi: Login dengan API Key khusus Demo |
| Demo | Layanan: Business Contoh endpoint global resmi: wss://wspap.okx.com/ws/v5/businessAutentikasi: Periksa fitur dan kanal yang didukung secara terpisah |
Kanal publik mencakup data yang tidak memerlukan autentikasi, seperti tickers·kuotasi·harga mark, sedangkan kanal Private mencakup akun·order·posisi, dan sebagainya. Tidak ada alasan untuk mengirim kunci rahasia demi menerima kanal publik. Sebaliknya, jika hanya tersambung ke alamat Private lalu berlangganan kanal akun tanpa respons login yang berhasil, data yang semestinya tidak akan diterima.
Perhatian terkait wilayah: Alamat di atas adalah contoh yang diverifikasi pada 24 Oktober 2026 dalam dokumentasi API global OKX. OKX mengarahkan pengguna untuk memakai domain API dan dokumentasi terpisah sesuai wilayah pendaftaran akun. Dokumentasi resmi mengarahkan akun US·AU yang terdaftar di app.okx.com untuk menggunakan dokumentasi US·AU dan domain API us.okx.com, sementara akun EU yang terdaftar di my.okx.com diarahkan untuk menggunakan dokumentasi EU dan domain API eea.okx.com. Jangan mengganti alamat REST API ini secara sembarangan dengan alamat WebSocket; periksa alamat WebSocket di dokumentasi wilayah terkait. Cara VPN atau akun ganda untuk mengakali pembatasan wilayah tidak dibahas dalam artikel ini.
Urutan aman dari koneksi hingga siap digunakan
- Tetapkan lingkungan. Pisahkan file konfigurasi·API Key·alamat WebSocket untuk perdagangan riil dan Demo.
- Periksa spesifikasi kanal. Pilih layanan yang ditetapkan kanal, yaitu Public·Private·Business, dan periksa persyaratan autentikasi untuk kanal Private. Jangan mengirim semua kanal ke alamat Public hanya karena datanya berupa harga pasar.
- Batasi kecepatan koneksi. Siapkan antrean koneksi ulang terpusat agar tidak melampaui batas 3 koneksi per detik berdasarkan IP.
- Login jika kanal memerlukan autentikasi. Ini mencakup kanal Private dan
orders-algopada layanan Business. Jangan menganggap Business selalu tanpa autentikasi. Ikuti spesifikasi kanal, kirim login dengan API Key, Passphrase, timestamp dan sign, lalu periksacode: "0". - Berlangganan hanya kanal yang diperlukan. Sesuaikan nama kanal dan instType·instFamily·instId dengan spesifikasi terbaru, lalu simpan respons konfirmasi langganan.
- Mulai timer penerimaan. Tetapkan N kurang dari 30 detik dan mulai ulang timer setiap kali menerima pesan.
- Sinkronkan status. Ubah bot menjadi siap hanya setelah menyelaraskan snapshot dan stream pesanan, posisi, serta saldo.
- Tangani notifikasi pemutusan dan peningkatan versi. Jika koneksi terputus atau
64008ada notice, pulihkan koneksi dengan urutan: koneksi baru, autentikasi ulang, berlangganan ulang, lalu sinkronisasi ulang.
DISCONNECTED → CONNECTING → AUTHENTICATING
→ SUBSCRIBING → RESYNCING → READYJangan menganggap koneksi siap untuk melakukan pemesanan hanya karena soket koneksi telah terbuka. Lebih aman untuk beralih ke READY hanya setelah autentikasi dan konfirmasi langganan yang diperlukan, pemeriksaan status terkini sesuai karakteristik kanal, serta koreksi data yang terlewat saat stream tersambung selesai.
Tanda tangan login Private WebSocket
Login OKX WebSocket tampak mirip dengan tanda tangan pesanan REST, tetapi format inputnya ditetapkan secara khusus. Menurut dokumentasi resmi, timestamp adalah string Unix Epoch dalam satuan detik, dan metodenya selalu GET, sedangkan requestPath selalu /users/self/verify.
preHash = timestamp + "GET" + "/users/self/verify"
sign = Base64(HMAC_SHA256(preHash, SecretKey))| Kolom | Ketentuan dan hal yang perlu diperiksa |
|---|---|
| apiKey | Ketentuan: API Key yang dibuat untuk lingkungan tersebut Kesalahan yang sering terjadi: mencampuradukkan kunci Demo dan kunci perdagangan langsung |
| passphrase | Ketentuan: string terpisah yang ditentukan saat membuat kunci Kesalahan yang sering terjadi: mengiranya sebagai kata sandi login OKX |
| timestamp | Ketentuan: string Unix Epoch dalam satuan detik Kesalahan yang sering terjadi: mengirim nilai milidetik apa adanya atau menggunakan ulang nilai yang sudah lama |
| sign | Ketentuan: jalur GET tetap yang di-HMAC SHA256 lalu dikodekan dengan Base64 Kesalahan yang sering terjadi: menggunakan jalur endpoint REST, metode huruf kecil, atau keluaran Hex |
Permintaan login kedaluwarsa 30 detik setelah timestamp. Jika waktu server berbeda, periksa selisihnya menggunakan API waktu server REST pada OKX, lalu buat timestamp baru. Respons berhasil mencakup event: "login", code: "0" dan connId, sedangkan contoh kegagalan resmi adalah event: "error", code: "60009", msg: "Login failed.". Jangan langsung menyimpulkan penyebabnya hanya dari 60009; periksa lingkungan, waktu, Passphrase, tanda tangan, dan status kunci secara berurutan.
Informasi tentang pembuatan kunci, izin minimum, daftar IP yang diizinkan, dan ketentuan tidak aktif selama 14 hari tersedia di Panduan OKX pembuatan dan keamanan API Key. Jangan mencetak Secret Key ke log karena kesalahan login; catat secara terbatas panjang string input tanda tangan dan komponennya, tanpa nilai rahasia.
Perhatian tentang ketentuan penonaktifan API Key: Dokumentasi resmi OKX menjelaskan bahwa untuk WebSocket, hanya tindakan login yang dihitung sebagai penggunaan API Key; langganan atau pesanan setelah login tidak dihitung sebagai penggunaan. Jika kunci dengan izin Trade·Withdraw yang tidak terikat ke IP terkena ketentuan tidak aktif selama 14 hari, jangan berasumsi bahwa aktivitas data atau pesanan melalui koneksi terbuka akan memperbarui aktivitas kunci. Pertahankan daftar IP yang diizinkan dan izin minimum, serta periksa status kunci di Security Center. API Key Demo Trading dikecualikan dari ketentuan kedaluwarsa karena tidak aktif ini.
Penanganan ping·pong untuk mencegah koneksi terputus setelah 30 detik
Dokumentasi OKX menjelaskan bahwa koneksi dapat terputus secara otomatis jika langganan belum terbentuk atau tidak ada data yang dikirim selama lebih dari 30 detik. Cara mengatasinya lebih menyerupai timer berbasis penerimaan daripada ping dengan interval tetap sederhana.
- Mulai ulang timer N detik setiap kali menerima pesan respons. Tetapkan N kurang dari 30.
- Jika tidak ada pesan baru selama N detik, kirim string
ping—bukan objek JSON. - Tunggu string
pongsebagai respons. - Jika tidak ada respons dalam N detik berikutnya, tandai koneksi tersebut sebagai gagal, tutup, lalu sambungkan kembali.
Kanal aktif terus menerima data sehingga ping tambahan tidak selalu diperlukan. Kanal instrumen yang jarang diperdagangkan atau kanal akun dapat lama tanpa pesan sehingga tetap membutuhkan timer. Jangan menganggap frame ping WebSocket otomatis dari pustaka juga menjalankan pertukaran string ping·pong OKX; verifikasi lewat log penerimaan sebenarnya.
Mengelola 480 kali per jam dan 30 koneksi per kanal
Jumlah total permintaan login·subscribe·unsubscribe dalam satu koneksi dibatasi hingga 480 kali per jam. Batas ini terpisah dari batas koneksi per detik, jadi kondisi ketika koneksi tetap terjaga tetapi hanya permintaan langganan yang ditolak harus ditangani secara terpisah. Simpan status langganan kanal yang sudah ada dalam aplikasi, lalu saat menyambungkan ulang, kirim hanya kumpulan akhir langganan yang diperlukan sebanyak satu kali.
Kanal Orders, Account, Positions, Balance and positions, Position risk warning, Account greeks dibatasi 30 koneksi WebSocket per subakun dan kanal tertentu. Beberapa argumen kanal yang sama dalam satu koneksi dihitung satu kali; kanal berbeda dihitung terpisah. Saat berlangganan, catat connCount dari peristiwa channel-conn-count. Jika menerima channel-conn-count-error, cari konsumen duplikat alih-alih membuat koneksi tambahan.
Dokumentasi OKX menjelaskan bahwa pengiriman, pengubahan, dan pembatalan pesanan melalui WebSocket tidak terpengaruh oleh perubahan batas 30 koneksi kanal ini, tetapi batas laju per endpoint untuk operasi pesanan tetap berlaku. Beberapa batas pesanan REST dan WebSocket juga berbagi kuota, jadi periksa spesifikasi setiap API pesanan secara terpisah.
Periksa juga setelah respons keberhasilan langganan:Jika batas koneksi terlampaui, setelah respons keberhasilan langganan umum dapat muncul channel-conn-count-error dan langganan dapat dihentikan. Dokumentasi resmi menjelaskan bahwa biasanya langganan baru ditolak, tetapi dalam kasus tertentu koneksi yang sudah ada juga dapat dilepas. Lacak status langganan dan peristiwa batas berdasarkan connId, dan jangan menganggap satu ACK saja menjamin penerimaan data berkelanjutan.
Mencegah data hilang dan pesanan duplikat saat menyambungkan kembali
Masalah yang lebih berbahaya daripada koneksi yang terputus lalu tersambung kembali adalah tetap mempercayai status selama periode terputus. Jika menggunakan stream pesanan dan posisi privat, hentikan sementara pesanan otomatis segera setelah menyambungkan kembali, lalu periksa ulang pesanan terbuka, posisi, dan saldo saat ini untuk membandingkannya dengan status lokal.
- Atur penyambungan kembali dengan backoff eksponensial, penundaan acak, dan batas waktu tunggu maksimum.
- Gunakan satu koordinator agar beberapa worker tidak menyambungkan kembali secara bersamaan dari satu IP.
- Jangan kirim langganan Private sebelum login berhasil.
- Bedakan respons konfirmasi langganan dari status penerimaan per kanal. Untuk kanal yang hanya mengirim data saat terjadi perubahan, seperti kanal pesanan, jangan menyimpulkan bahwa langganan gagal hanya karena tidak ada aktivitas.
- Periksa duplikasi dan celah sesuai aturan timestamp·sequence·ID pesanan yang disediakan tiap kanal.
- Jika masih ada ketidakcocokan status, jangan lanjutkan kembali pembuatan, pengubahan, atau pembatalan pesanan.
- Untuk pesanan yang tidak menerima respons, periksa apakah pesanan diterima menggunakan ID pesanan klien yang unik dan pemeriksaan pesanan, lalu tentukan apakah perlu mencoba lagi. Jangan mengirim ulang pesanan yang sama hanya karena koneksi sudah pulih.
OKX menyatakan bahwa 60 detik sebelum peningkatan layanan WebSocket event: "notice", code: "64008" notifikasi dapat dikirim. Dalam kasus ini, jangan menunggu hingga koneksi lama terputus; buat koneksi baru dan selesaikan login, langganan, serta sinkronisasi status, lalu beralih dengan aman. Notice tersebut secara tegas dinyatakan didukung saat ini pada WebSocket Public dan Private.
Jika kesalahan tanda tangan·timestamp·lingkungan muncul bersamaan, lihat Panduan OKX mengatasi kesalahan API 50113·50102. Jika struktur leverage dan likuidasi untuk pesanan otomatis belum diverifikasi, lebih aman membaca Panduan OKX pemula perdagangan futures terlebih dahulu, lalu menguji seluruh alur pemulihan di Demo.
Data awal kanal Order: Spesifikasi kanal Orders resmi menyatakan bahwa data tidak dikirim saat pertama kali berlangganan, tetapi hanya saat ada pesanan baru atau perubahan pesanan. Karena itu, jangan menunggu semua pesanan lama yang belum selesai dikirim otomatis setelah konfirmasi langganan. Berikut adalah rencana operasional pemulihan untuk AKEYX, bukan berarti platform menyediakan fungsi pemutaran ulang yang sama untuk semua kanal.
- Hentikan pesanan otomatis, lalu simpan sementara pembaruan yang masuk setelah login dan konfirmasi langganan selesai pada koneksi pemulihan.
- Gunakan REST API resmi untuk memeriksa pesanan terbuka, posisi, dan saldo saat ini. Pesanan yang tidak ditemukan di daftar pesanan terbuka mungkin telah dibatalkan atau terisi, jadi periksa juga detail dan riwayat pesanan sesuai kebutuhan.
- Bandingkan ID pesanan, waktu pembaruan, jumlah terisi kumulatif, dan lainnya sesuai spesifikasi kanal terkait, lalu hapus duplikat. Jangan berasumsi semua kanal memiliki sequence atau snapshot awal yang sama.
- Jika urutan respons REST dan peristiwa yang disimpan tidak jelas, lakukan pemeriksaan ulang untuk memastikan konsistensi. Jika masih ada ketidaksesuaian atau status penerimaan pesanan tidak jelas, jangan beralih ke
READY.
Penyebab dan tindakan pertama berdasarkan gejala
| Gejala | Kondisi dan hal yang perlu diperiksa |
|---|---|
| Terputus sekitar setiap 30 detik | Kemungkinan penyebab utama: ping·pong tidak ditangani selama jeda tanpa aktivitas Bukti yang perlu diperiksa terlebih dahulu: waktu terakhir menerima data, teks ping, dan respons pong Tindakan yang harus dihindari: menyambungkan ulang seketika tanpa batas |
| 60009 Login gagal | Kemungkinan penyebab utama: ketidakcocokan lingkungan, timestamp, Passphrase, atau tanda tangan Bukti yang perlu diperiksa terlebih dahulu: lingkungan pembuatan kunci, waktu dalam satuan detik, jalur GET tetap Tindakan yang harus dihindari: mencetak Secret Key ke log |
| Konfirmasi langganan tidak diterima | Kemungkinan penyebab utama: kesalahan layanan, kanal, atau argumen, atau batas terlampaui Bukti yang perlu diperiksa terlebih dahulu: alamat Public/Private, error code·msg, ukuran permintaan Tindakan yang harus dihindari: mengulang subscribe yang sama tanpa batas |
| channel-conn-count-error | Kemungkinan penyebab utama: melebihi 30 koneksi untuk kanal yang dibatasi Bukti yang perlu diperiksa terlebih dahulu: daftar connId per subakun dan kanal Tindakan yang harus dihindari: terus menambahkan proses baru |
| Kekosongan data saat peningkatan versi | Kemungkinan penyebab utama: mengabaikan notice 64008 Bukti yang perlu diperiksa terlebih dahulu: waktu penerimaan notice dan waktu persiapan koneksi baru Tindakan yang harus dihindari: baru memulai koneksi setelah koneksi lama berakhir |
| Pesanan duplikat setelah koneksi ulang | Kemungkinan penyebab utama: status lokal tidak disinkronkan·percobaan ulang tanpa batas Bukti yang perlu diperiksa terlebih dahulu: client order ID, snapshot pesanan terbuka dan posisi Tindakan yang harus dihindari: melanjutkan pesanan otomatis sebelum READY |
Daftar periksa sebelum operasional
- □ Apakah Anda telah membuka dokumentasi API resmi yang sesuai dengan wilayah dan lingkungan akun Anda?
- □ Apakah alamat Public·Private·Business dan pengaturan perdagangan live·Demo telah dipisahkan?
- □ Apakah batas permintaan koneksi 3 kali per detik berdasarkan IP dikelola secara terpusat?
- □ Apakah timestamp login WebSocket menggunakan satuan detik dan dikirim dalam 30 detik?
- □ Apakah kunci rahasia dan Passphrase dikecualikan dari log dan layanan pelacakan kesalahan?
- □ Apakah penghitung 480 operasi per jam per koneksi dan ukuran langganan 64KB dipantau?
- □ Apakah connId dan connCount per subakun untuk kanal yang dibatasi dicatat?
- □ Apakah tersedia timer penerimaan yang lebih singkat dari 30 detik serta penanganan kegagalan ping·pong?
- □ Apakah notice 64008, pemutusan jaringan, dan kegagalan autentikasi ditangani sebagai status yang berbeda?
- □ Apakah pesanan diblokir sampai sinkronisasi snapshot dan stream selesai setelah koneksi ulang?
Untuk pengaturan perlindungan akun dan penanganan kebocoran kunci, periksa juga OKX panduan keamanan dan perlindungan akun. Stabilitas koneksi dan keamanan adalah dua hal yang berbeda, dan tingkat ketersediaan yang tinggi tidak membuat pesanan berisiko menjadi aman.
Pertanyaan yang sering diajukan
Apakah saya memerlukan kunci API jika hanya menerima data pasar?
Secara umum, kanal publik seperti tickers·buku pesanan tidak memerlukan autentikasi. Periksa alamat layanan Public·Business pada spesifikasi kanal yang berlaku, dan jangan kirim kunci rahasia. Kanal Private seperti akun·pesanan·posisi memerlukan login.
Apakah saya harus mengirim ping tepat setiap 30 detik?
Panduan resmi menyarankan untuk menetapkan N kurang dari 30 detik, mengatur ulang timer setiap kali pesan diterima, lalu mengirim teks ping jika tidak ada respons selama N detik. Jika pong tidak diterima dalam N detik berikutnya, tangani sebagai kesalahan atau lakukan koneksi ulang.
Apakah batas 480 kali per jam merupakan batas jumlah pesan data pasar?
Bukan. Batas tersebut berlaku pada total permintaan login·subscribe·unsubscribe per koneksi. Cakupannya berbeda dari jumlah data pasar yang dikirim server atau batas kecepatan per endpoint pesanan.
Apakah batas 30 koneksi berlaku untuk semua WebSocket?
Bukan. Batas ini dihitung per subakun dan kanal untuk kanal privat tertentu yang tercantum dalam dokumentasi resmi, seperti Orders·Account·Positions·Balance and positions·Position risk warning·Account greeks. Periksa peristiwa connCount untuk setiap kanal.
Jika berfungsi dengan baik di Demo, apakah saya bisa langsung menghubungkannya dengan cara yang sama untuk perdagangan live?
Demo dan perdagangan live harus menggunakan endpoint dan kunci API yang terpisah, dan dukungan untuk beberapa fitur mungkin berbeda. Meskipun pengaturannya disalin, verifikasi kembali ukuran pesanan·mode akun·izin·domain wilayah·prosedur pemulihan sesuai kondisi perdagangan live.
Apakah penggunaan OKDCC meningkatkan batas WebSocket?
Tidak. Kode referral tidak terkait dengan batas kecepatan koneksi·langganan·pesanan WebSocket ataupun stabilitas API. Ketersediaan dan ketentuan rabat biaya tidak diterapkan secara otomatis atau tanpa syarat, dan dapat berbeda menurut akun·wilayah·VIP·kampanye. Sebelum mendaftar, periksa layar pendaftaran, lalu periksa persentase yang benar-benar berlaku di My Rewards setelah mendaftar.
Sumber resmi dan tanggal peninjauan
- OKX API V5: Keamanan Kunci API — kondisi penghitungan hanya saat kunci digunakan untuk login WebSocket dan aturan tidak aktif selama 14 hari
- OKX API V5: Ikhtisar WebSocket — metode koneksi, perbedaan Public·Private
- OKX API V5: Koneksi WebSocket — 3 permintaan koneksi per detik per IP; total 480 operasi login·subscribe·unsubscribe per koneksi per jam; timer penerimaan N < 30 detik dan string ping·pong
- OKX API V5: Batas Jumlah Koneksi — kanal yang dibatasi, 30 per subakun·kanal, peristiwa connCount
- OKX API V5: Login WebSocket — timestamp dalam satuan detik, jalur tanda tangan tetap, kedaluwarsa 30 detik, 60009
- OKX API V5: Berlangganan — kanal publik·privat, argumen langganan dan ketentuan 64KB
- OKX API V5: Notifikasi — notice 64008 60 detik sebelum peningkatan layanan
- OKX API V5: Layanan Perdagangan Live — alamat REST·WebSocket untuk perdagangan live
- OKX API V5: Layanan Perdagangan Demo — alamat·kunci khusus Demo dan cakupan dukungan
- OKX API V5: Saluran Pesanan — data awal tidak dikirim saat berlangganan pertama kali, diperbarui saat ada pesanan baru atau perubahan pesanan
- OKX API V5: Algo Orders Channel —
orders-algo·/ws/v5/business· login
Terakhir ditinjau: 25 Oktober 2026. Alamat koneksi, domain regional, daftar saluran, batas kecepatan dan koneksi, serta fitur yang didukung Demo dapat berubah. Periksa kembali angka dan endpoint di OKX dokumentasi resmi untuk wilayah akun Anda saat dijalankan, dan terapkan prosedur koneksi ulang serta sinkronisasi status dari AKEYX sebagai panduan analisis untuk mengurangi risiko operasional.