API Exchange Kripto untuk Arbitrase: REST vs WebSocket, Rate Limit, dan API Key yang Aman Oktober 1, 2026 – Posted in: Arbitrage Software, cryptoarbitrage software
Menghubungkan Bot ke API Exchange Kripto untuk Arbitrase: REST, WebSocket, Rate Limit, dan Latensi
Peluang arbitrase hanya ada selama bot Anda bisa melihatnya dan bertindak atasnya. Keduanya bergantung pada cara Anda terhubung ke setiap exchange. Panduan ini menjelaskan pilihan-pilihan yang menentukan apakah selisih harga berubah menjadi order yang terisi atau justru peluang yang terlewat: jenis API mana yang dipakai, bagaimana rate limit bekerja di Binance, Bybit, OKX, MEXC dan Gate.io, cara membuat API key yang aman, serta ke mana saja milidetik Anda terbuang.
Mengapa koneksi API menentukan hasil arbitrase
Di atas kertas, arbitrase antar-exchange terlihat sederhana: beli di tempat yang harganya lebih rendah, jual di tempat yang harganya lebih tinggi, lalu ambil selisihnya setelah dipotong biaya. Dalam praktiknya, selisih itu biasanya hanya bertahan dari beberapa ratus milidetik hingga beberapa menit, dan seluruh transaksi berlangsung melalui API exchange. Ada tiga faktor teknis yang menentukan berapa yang benar-benar Anda dapatkan:
- Seberapa cepat Anda melihat harga. Jika kuotasi Anda terlambat, selisih yang Anda hitung mungkin sudah hilang.
- Seberapa cepat order Anda sampai. Dua leg harus terisi di dua venue; leg yang lebih lambat menentukan harga entry Anda yang sebenarnya.
- Seberapa sering Anda boleh mengirim permintaan. Rate limit membatasi jumlah request. Bot yang menabrak batas ini akan diblokir tepat saat pasar paling ramai dan selisih harga paling lebar.
Semua ini tidak terlihat dalam backtest, itulah sebabnya dua bot yang menjalankan strategi yang sama bisa memberikan hasil yang sangat berbeda. Jika Anda belum mengukur selisih harga antar-exchange yang Anda gunakan, mulailah dengan crypto arbitrage scanner gratis kami: alat ini menunjukkan pair dan venue mana yang menghasilkan selisih harga cukup besar untuk menutup biaya.
REST vs WebSocket: kegunaan masing-masing
Setiap exchange besar menyediakan dua cara untuk berkomunikasi dengannya.
REST API bekerja dengan pola request dan response. Bot mengirim HTTP request yang sudah ditandatangani (misalnya “berikan order book” atau “pasang order ini”) lalu menunggu jawabannya. Setiap request berdiri sendiri, mudah di-debug, dan dihitung terhadap rate limit.
WebSocket API menjaga satu koneksi tetap terbuka. Setelah Anda berlangganan (subscribe) ke sebuah channel, exchange akan mengirimkan setiap pembaruan (perubahan order book, transaksi, status order Anda sendiri) saat itu juga. Tidak ada polling dan tidak ada jeda buta di antara pengecekan.
| REST | WebSocket | |
|---|---|---|
| Data pasar | Snapshot saat diminta; perubahan di antara polling terlewat | Stream berkelanjutan berisi pembaruan order book dan transaksi |
| Penggunaan umum dalam arbitrase | Arbitrase hedge (antar-exchange) dengan selisih yang bertahan beberapa detik atau lebih; saldo; penarikan | Arbitrase latensi dan strategi apa pun dengan selisih yang bertahan kurang dari satu detik |
| Tekanan rate limit | Tinggi: setiap pengecekan harga memakan weight | Rendah untuk data: satu subscription menggantikan ribuan request |
| Kompleksitas | Rendah | Lebih tinggi: reconnect, nomor urut (sequence number), pemeliharaan order book lokal |
Sebagian besar setup profesional menggabungkan keduanya: WebSocket untuk data pasar dan pembaruan order, REST (atau endpoint trading WebSocket milik exchange, jika tersedia) untuk memasang order, dan REST untuk panggilan administratif yang lambat seperti saldo dan transfer.
Inilah juga perbedaan praktis antara dua bot kripto kami. VIP Crypto Arbitrage terhubung lewat REST ke lebih dari 35 exchange dan dirancang untuk arbitrase hedge antar-exchange, di mana selisih harga bertahan cukup lama. SharpTrader Pro menggunakan feed WebSocket dari lebih dari 40 exchange, yang mutlak diperlukan untuk arbitrase latensi dengan jendela peluang 100–500 ms.
Rate limit di exchange-exchange besar
Rate limit adalah penyebab paling umum bot arbitrase berhenti bekerja saat live trading. Setiap exchange menghitung request Anda per alamat IP, per akun (UID), atau per API key, lalu memblokir atau mem-ban Anda jika kuota terlampaui. Tabel di bawah merangkum aturan yang dipublikasikan saat artikel ini ditulis (September 2026). Batasan ini sering berubah, jadi selalu periksa dokumentasi exchange dan baca header limit pada response live.
| Exchange | Batas utama REST | Yang terjadi jika terlampaui | Detail berguna |
|---|---|---|---|
| Binance (Spot) | Request weight 6.000 per menit per IP; batas jumlah order terpisah. Setiap endpoint memiliki weight sendiri | HTTP 429; tetap mengirim request setelah 429 berujung pada HTTP 418 dan ban IP otomatis mulai dari 2 menit hingga 3 hari untuk pelanggar berulang | Header X-MBX-USED-WEIGHT-* dan X-MBX-ORDER-COUNT-* menunjukkan pemakaian saat ini; Retry-After memberi tahu berapa lama harus menunggu |
| Bybit (V5) | 600 request per 5 detik per IP; batas per UID untuk trading, misalnya create order 20/s di spot dan 10/s di kontrak linear | Batas IP: HTTP 403 “access too frequent”, dicabut setelah sekitar 10 menit; batas UID: retCode 10006 | Header X-Bapi-Limit, X-Bapi-Limit-Status, X-Bapi-Limit-Reset-Timestamp |
| OKX (V5) | Batas ditetapkan per endpoint dan per instrumen, dan tier VIP yang lebih tinggi mendapat kapasitas lebih besar | Response error untuk endpoint tersebut; penyalahgunaan berulang dapat membatasi key | Channel order book: bbo-tbt (best bid/ask, setiap 10 ms), books5 (setiap 100 ms), books (inkremental, 100 ms); channel L2 tick-by-tick memerlukan level VIP yang lebih tinggi |
| MEXC (Spot v3) | Endpoint ber-weight IP berbagi 300 weight per 10 detik; endpoint ber-weight UID 500 weight per 10 detik | HTTP 429 dengan Retry-After; pelanggaran berulang berujung pada ban IP mulai dari 2 menit hingga 3 hari |
WebSocket: hingga 30 stream per koneksi, 100 pesan per detik; koneksi ditutup setelah 60 detik tanpa lalu lintas (balas ping) |
| Gate.io (API v4) | Batas per key yang dipublikasikan untuk endpoint spot publik dan privat, dengan batas yang jauh lebih tinggi untuk pembatalan order | Request yang mendekati ambang burst ditunda, request yang melampauinya ditolak | WebSocket: hingga 300 koneksi per IP |
Tiga aturan untuk menjaga bot tetap di dalam batas:
- Ambil data pasar dari WebSocket, bukan REST. Bot yang melakukan polling order book 20 pair di 5 exchange setiap 200 ms mengirim 500 request per detik. Data yang sama lewat WebSocket hanya membutuhkan beberapa subscription.
- Baca header limit dan perlambat bot sebelum exchange yang melakukannya untuk Anda. Bot yang mundur (back off) saat mencapai 80% kuota tidak akan pernah terkena ban.
- Pisahkan lalu lintas. Gunakan API key (atau sub-account) yang berbeda untuk bot yang berbeda, agar skrip yang lepas kendali tidak memblokir key trading Anda.
Membuat API key dengan aman
Bot arbitrase membutuhkan izin untuk membaca saldo dan memasang order. Bot ini tidak pernah membutuhkan izin penarikan (withdrawal). API key yang bocor tanpa hak penarikan memang masih bisa menimbulkan kerugian lewat transaksi yang buruk, tetapi tidak bisa menguras akun.
- Buat satu key per exchange dan per bot, dan beri nama sesuai bot dan servernya.
- Aktifkan hanya izin baca dan trading spot/futures. Biarkan penarikan tetap nonaktif.
- Batasi key ke alamat IP VPS Anda. Sebagian besar exchange mendukung IP whitelist; key yang dibatasi ke satu IP tidak berguna di mesin lain mana pun.
- Simpan secret dalam bentuk terenkripsi di server, jangan pernah di screenshot, chat, atau dokumen bersama.
- Ganti (rotasi) key setelah ada pergantian staf, migrasi server, atau dugaan kebocoran, dan hapus key yang tidak lagi Anda gunakan.
- Untuk strategi yang terpisah, gunakan sub-account: saldo dan rate limit-nya terisolasi.
Dari mana latensi berasal dan cara memangkasnya
Sejak harga berubah di exchange hingga order Anda terisi, waktu terpakai di lima titik: pembaruan pasar dikirim ke server Anda, bot Anda mendeteksi selisih, order yang sudah ditandatangani dikirim kembali, exchange mencocokkannya (matching), dan konfirmasi dikirim balik. Pada bot yang ditulis dengan baik, pemrosesan hanya memakan beberapa milidetik. Jaringanlah yang biasanya paling dominan.
- Tempatkan bot di dekat exchange. Sebagian besar exchange besar menjalankan matching engine mereka di region cloud tertentu (banyak di Tokyo, Singapura, atau Hong Kong). VPS di region yang sama dapat memangkas waktu round-trip dari puluhan milidetik menjadi hanya beberapa milidetik. Panduan kecepatan VPS kami menjelaskan cara mengukurnya.
- Untuk strategi multi-exchange, pilih lokasi yang meminimalkan leg yang lebih lambat, bukan rata-ratanya: transaksi hanya secepat fill yang paling lambat.
- Jaga koneksi tetap “hangat”. Gunakan ulang koneksi HTTPS (keep-alive) dan tandatangani lebih dulu apa yang bisa; membuka koneksi TLS baru untuk setiap order menambah satu round trip penuh.
- Ukur secara terus-menerus. Catat timestamp exchange dari setiap pembaruan terhadap jam lokal Anda (disinkronkan dengan NTP) dan pantau usia kuotasi yang dipakai bot Anda untuk bertransaksi.
Menjaga koneksi tetap andal
Koneksi WebSocket bisa terputus. Exchange menutup stream yang idle, me-restart server, dan membatasi masa hidup koneksi. Bot yang tangguh sudah mengantisipasinya:
- Heartbeat: balas ping (MEXC menutup koneksi setelah 60 detik tanpa lalu lintas) dan kirim ping Anda sendiri jika exchange mewajibkannya.
- Pengecekan urutan: stream order book inkremental membawa ID pembaruan. Jika ada yang hilang, buang order book lokal dan sinkronkan ulang dari snapshot baru, alih-alih bertransaksi dengan order book yang rusak.
- Reconnect otomatis dengan back-off: sambungkan ulang dengan cepat, tetapi jangan dalam loop yang rapat; Bybit, misalnya, membatasi koneksi baru per jendela 5 menit.
- Pengaman data basi (stale data): jika tidak ada pembaruan untuk sebuah pair dalam waktu yang ditentukan, hentikan trading pair tersebut sampai stream pulih.
- Rekonsiliasi status order: setelah reconnect, cek order terbuka dan posisi lewat REST sebelum memasang order baru, agar hedge yang baru terisi sebagian tidak pernah terlupakan.
- Ikuti pemberitahuan perubahan API. Exchange menghentikan endpoint dan mengubah batasan beberapa kali dalam setahun. Pelacak perubahan API exchange kripto kami mengumpulkan pengumuman-pengumuman ini di satu tempat.
Checklist sebelum go-live
- Selisih harga pada pair Anda sudah dikonfirmasi dengan scanner, setelah dipotong biaya.
- Satu API key per exchange: hanya trading, penarikan nonaktif, IP whitelist sudah diatur.
- Data pasar lewat WebSocket; panggilan REST hanya untuk order dan data akun.
- Header rate limit dicatat; bot mundur sebelum mencapai 80% kuota.
- VPS berada di region yang meminimalkan leg paling lambat; waktu round-trip sudah diukur.
- Pengaman reconnect, resinkronisasi, dan data basi sudah diuji dengan sengaja memutus jaringan.
- Jalankan live pertama dengan ukuran minimum, lalu bandingkan fill dengan harga yang dilihat bot.
Biarkan software yang mengurus urusan teknisnya
Penanganan koneksi, penandatanganan request, rate limit, dan reconnect sudah terpasang di bot kami. Mulailah dengan scanner gratis, lalu pilih bot yang sesuai dengan strategi Anda.
Crypto arbitrage scanner gratis Bandingkan bot arbitrase kripto
FAQ
Apakah saya membutuhkan WebSocket untuk arbitrase kripto?
Untuk arbitrase latensi, ya: peluangnya bertahan kurang dari satu detik dan polling tidak dapat melihatnya tepat waktu. Untuk arbitrase hedge (antar-exchange), di mana selisih harga bertahan beberapa detik atau menit, REST sudah cukup, tetapi WebSocket tetap mengurangi pemakaian rate limit.
Mengapa bot saya mendapat error HTTP 429 atau 418 di Binance?
429 berarti Anda melampaui batas request; 418 berarti IP Anda di-ban karena request tetap dikirim setelah 429. Pindahkan data pasar ke WebSocket, patuhi header Retry-After, dan perlambat bot sebelum mencapai batas.
Apakah API key untuk arbitrase perlu mengizinkan penarikan?
Tidak. Izin trading dan baca sudah cukup. Rebalancing antar-exchange bisa dilakukan secara manual atau melalui proses terpisah yang dibatasi dengan ketat.
Lokasi server mana yang terbaik untuk arbitrase di beberapa exchange?
Lokasi yang meminimalkan leg paling lambat dari transaksi Anda. Ukur waktu round-trip dari region kandidat ke API setiap exchange sebelum memutuskan.
Seberapa sering API exchange berubah?
Beberapa kali dalam setahun untuk setiap exchange: endpoint baru, versi yang dihentikan, dan batasan yang diubah. Berlangganan pengumuman API dari setiap exchange dan pantau pelacak perubahan API kami.
