Batas laju API bursa kripto: arti error 429 dan cara tetap di bawahnya
HTTP 429 berarti Anda mengirim terlalu banyak permintaan dalam waktu tertentu, dan server meminta Anda melambat. Ini bukan insiden. Setiap bursa menghitung permintaan secara berbeda: Binance memakai bobot untuk tiap endpoint dan memblokir alamat IP yang terus berlanjut setelah 429, Bybit memblokir IP yang melewati 600 permintaan dalam lima detik, dan OKX menetapkan batas per endpoint serta mengembalikan kode error 50011. Tetap di bawah batas berarti membaca header respons, mundur dengan benar, dan memakai WebSocket jika bisa.
Saat mendapat 429, berhenti dan tunggu sebelum mencoba lagi; jangan langsung mengulang. Baca header yang melaporkan pemakaian Anda, patuhi Retry-After jika ada, dan ganti polling dengan aliran WebSocket. Mengabaikan 429 berulang di Binance berujung pada blokir IP otomatis.
Arti 429 sebenarnya
HTTP 429 Too Many Requests adalah kode status standar yang didefinisikan persis untuk situasi ini. Referensi MDN menggambarkannya sebagai klien yang mengirim terlalu banyak permintaan dalam waktu tertentu, dan mencatat bahwa header Retry-After mungkin memberi tahu berapa lama harus menunggu. Batas laju bisa berlaku untuk seluruh server atau satu sumber daya, dan sering berdasarkan alamat IP, meski bisa juga terkait aplikasi atau pengguna.
Ini pesan yang berguna, bukan kegagalan. Pesan ini memberi tahu layanan berfungsi, Anda dikenali, dan apa yang harus dilakukan selanjutnya. Saat mengukur ketersediaan di situs ini, kami menyimpan kategori terpisah untuk pembatasan laju, agar tidak melaporkan bursa down hanya karena permintaan dibatasi.
Cara Binance menghitung: bobot permintaan dan blokir IP
Dokumentasi API futures Binance menggambarkan sistem bobot. Setiap rute punya bobot, dan endpoint yang lebih berat, atau yang menangani banyak simbol, berbiaya lebih besar. Batas Anda adalah total bobot per interval, bukan sekadar jumlah permintaan. Batas saat ini muncul di larik rateLimits pada /fapi/v1/exchangeInfo.
Poin penting dari dokumentasi:
- Setiap respons menyertakan
X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter), yang menunjukkan bobot terpakai saat ini untuk IP Anda. - 429 dikembalikan saat salah satu batas laju terlampaui.
- Berulang kali melampaui batas, atau tidak mundur setelah 429, berujung pada blokir IP otomatis dengan status 418.
- Durasi blokir meningkat bagi pelanggar berulang, dari 2 menit hingga 3 hari.
- Batas IP berdasarkan alamat IP dan bukan kunci API, jadi beberapa program di satu mesin berbagi satu anggaran.
- Batas laju order dilacak terpisah, dan respons order menyertakan header hitungannya sendiri.
Cara Bybit menghitung: per IP dan per pengguna
Dokumentasi v5 Bybit menggambarkan dua lapisan. Pada lapisan IP, Anda diizinkan 600 permintaan dalam jendela lima detik per IP secara default, untuk lalu lintas ke hostname API utamanya. Jika melebihinya, Anda mendapat error 403, access too frequent, dan dokumentasi menyatakan Anda harus menghentikan semua sesi HTTP dan menunggu setidaknya 10 menit, setelah itu blokir dicabut otomatis. Perhatikan ini 403, bukan 429, yang sering mengecoh.
Pada lapisan API, batas berlaku untuk tiap pengguna dalam jendela bergulir, dan melampauinya mengembalikan retCode 10006 dengan Too many visits! di JSON. Header respons melaporkan posisi Anda:
X-Bapi-Limit-Statusmenunjukkan sisa permintaan untuk endpoint saat ini.X-Bapi-Limitmenunjukkan batas Anda saat ini untuk endpoint itu.X-Bapi-Limit-Reset-Timestampmenunjukkan kapan batas diatur ulang, jika Anda melampauinya.
Bybit juga menyarankan agar aplikasi tidak berjalan di tepi batas ini, karena aktivitas jaringan yang tidak biasa bisa menyebabkan pelanggaran tak terduga. Koneksi WebSocket punya batas sendiri.
Cara OKX menghitung: per endpoint dan per instrumen
Dokumentasi API OKX menyatakan bahwa permintaan yang ditolak mengembalikan kode error 50011, dan batasnya berbeda untuk tiap endpoint serta tercantum di detail tiap endpoint. Batas REST publik tanpa autentikasi berdasarkan alamat IP, dan batas login serta langganan WebSocket berdasarkan koneksi. Untuk API trading, penempatan, perubahan, dan pembatalan order punya batas terpisah, umumnya didefinisikan per instrumen dan dibagi antara REST dan WebSocket.
Pelajaran dari ketiganya: jangan mengasumsikan aturan satu bursa pada bursa lain. Kode status, satuan hitungan, dan hukumannya bisa berbeda, dan semuanya berubah seiring waktu, jadi kembali ke dokumentasi terkini.
Mengapa Anda mencapai batas tanpa bermaksud
Kebanyakan masalah batas laju tidak berasal dari satu loop sibuk. Masalahnya berasal dari penyebab yang kurang jelas.
- Alamat IP bersama. Banyak bot, gateway NAT cloud, atau VPN bersama semuanya dihitung pada satu alamat. Tetangga Anda bisa menghabiskan anggaran Anda.
- Endpoint berat. Mengambil semua ticker atau order book dalam bisa berbiaya berkali-kali lipat permintaan satu simbol. Sepuluh di antaranya bisa setara ratusan panggilan sederhana.
- Badai percobaan ulang. Kegagalan singkat membuat setiap pekerja mengulang sekaligus. Ledakan itu mendorong Anda ke 429, yang memicu lebih banyak percobaan ulang.
- Loop restart. Program yang memuat ulang statusnya saat mulai, dan berulang kali crash lalu mulai lagi, bisa menghabiskan seluruh anggaran hanya untuk memulai.
- Polling untuk yang bisa disediakan aliran. Menanyakan harga setiap detik pada 50 simbol adalah 3.000 permintaan semenit, dan WebSocket bisa memberikan data yang sama dengan biaya jauh lebih kecil.
Cara mundur dengan benar
Saat mendapat respons batas, perilaku yang benar itu sederhana dan layak diterapkan sekali, di satu tempat.
- Berhenti mengirim ke bursa itu selama waktu yang diminta. Jika ada header
Retry-Afteratau timestamp reset, ikuti. Jika tidak, tunggu, mulai dari sekitar satu detik. - Gunakan exponential backoff dengan jitter. Gandakan waktu tunggu setelah tiap kegagalan berturut-turut, sampai batas, dan tambahkan keacakan agar beberapa pekerja tidak mengulang bersamaan.
- Bagi limiter antar pekerja. Satu token bucket per IP dan per bursa, dibagi semua proses di alamat itu, jauh lebih efektif daripada tiap pekerja menebak sendiri.
- Lacak pemakaian terus-menerus. Baca header bobot terpakai pada tiap respons dan melambat saat mendekati batas, bukan menunggu diberi tahu.
- Perlakukan 418 dan blokir IP sebagai sinyal berhenti. Berhenti dan beri tahu manusia. Melanjutkan memperpanjang blokir.
Cara memakai lebih sedikit permintaan
Permintaan termurah adalah yang tidak Anda kirim.
- Gunakan WebSocket untuk data pasar dan pembaruan akun. Satu aliran menggantikan polling terus-menerus, dan pembaruan juga tiba lebih cepat.
- Cache data yang lambat berubah. Spesifikasi kontrak dan jadwal biaya jarang berubah. Ambil sesekali, bukan pada setiap jalannya program.
- Gunakan endpoint batch dengan hati-hati. Endpoint ini bisa menghemat banyak permintaan, tetapi periksa bobotnya, karena per panggilan lebih mahal.
- Minta hanya kedalaman yang diperlukan. Permintaan order book dalam lebih mahal, dan banyak tugas hanya perlu beberapa tingkat pertama.
- Hindari polling status order dalam loop. Aliran data pengguna memberi tahu saat order terisi.
Jika Anda hanya memerlukan funding rate atau angka keandalan, Anda mungkin tidak perlu mem-polling bursa sama sekali. Kami menerbitkan data sebagai berkas JSON gratis, diperbarui terjadwal, meski tidak boleh dipakai untuk keputusan trading yang memerlukan data langsung.
429 saat darurat
Waktu terburuk menemui batas adalah saat mencoba membatalkan order di pasar yang jatuh. Loop Anda menghantam API, anggaran habis, dan kini pembatalan ditolak. Rencanakan ini: simpan lalu lintas terkait order dalam anggaran yang dicadangkan, terpisah dari polling data pasar. Simpan data publik pada aliran agar tidak memakai anggaran REST. Dokumentasi Binance mencatat bahwa saat node server berada dalam perlindungan tingkat sistem dan membatasi permintaan, order close-position, reduce-only, dan pembatalan dikecualikan, yang menunjukkan bahwa memakai jenis order itu untuk mengurangi risiko adalah kebiasaan bijak. Panduan apa yang harus dilakukan saat insiden kami membahas persiapan terkait.
Batas atau insiden?
Keduanya bisa terlihat serupa di dasbor, karena sama-sama menghasilkan kegagalan. Pisahkan menurut kode.
- 429, 418, atau kode batas khusus bursa: lalu lintas Anda sendiri kemungkinan penyebabnya.
- 403: bisa firewall web, blokir wilayah, atau batas IP Bybit. Lihat panduan 403 dan 451 kami.
- 5xx atau timeout: mungkin di sisi bursa atau di sepanjang rute. Periksa apakah bursa down.
Catat kode, endpoint, dan header respons untuk setiap kegagalan. Tanpanya Anda hanya menebak.
Pertanyaan umum tentang batas laju
Apakah memakai beberapa kunci API menghindari batas?
Tidak untuk batas berbasis IP, seperti bobot IP Binance. Beberapa kunci dari alamat yang sama berbagi anggaran yang sama. Batas laju order mungkin dilacak per akun, jadi periksa cara tiap jenis batas dihitung. Menyebar lalu lintas ke banyak alamat khusus untuk menghindari batas bisa melanggar syarat bursa, dan kami tidak menyarankannya.
Berapa lama blokir batas laju berlangsung?
Tergantung bursanya. Dokumentasi Binance menyatakan blokirnya meningkat dari 2 menit hingga 3 hari bagi pelanggar berulang. Bybit menyatakan Anda harus menunggu setidaknya 10 menit setelah 403, access too frequent. Terus mengirim permintaan saat diblokir berisiko memperpanjangnya.
Bisakah saya meminta batas lebih tinggi?
Sebagian bursa menawarkan batas lebih tinggi untuk market maker, tingkat VIP, atau lewat pengajuan. Lihat dokumentasinya. Biasanya langkah pertama yang lebih baik adalah mengurangi lalu lintas yang tidak perlu, karena itu juga membuat sistem Anda lebih tangguh.
Seberapa dekat batas yang masih aman?
Tidak ada angka pasti, tetapi sisakan ruang alih-alih menargetkan seluruh batas. Jaga pemakaian normal jauh di bawahnya agar ada tempat untuk permintaan tambahan saat badai percobaan ulang atau restart.
Tetap di bawah batas
- Baca aturan batas laju untuk API yang tepat Anda pakai.
- Catat header bobot terpakai dan melambat sebelum mencapai batas.
- Bagi satu limiter antar semua pekerja pada satu IP.
- Pada respons batas, mundur dengan jitter dan patuhi Retry-After.
- Berhenti dan beri peringatan pada 418 atau blokir.
- Pindahkan data pasar ke WebSocket.
- Cadangkan anggaran untuk pembatalan.
Angka dalam panduan ini untuk menunjukkan metodenya dan bukan nasihat investasi. Untuk keputusan Anda, ambil nilai terkini dari halaman resmi bursa, ulangi perhitungan dengan posisi Anda sendiri, dan bandingkan hasilnya dengan riwayat transaksi. Jika Anda melihat kesalahan pada data kami, tulis ke alamat di halaman tentang kami; koreksi kami terbitkan dengan menjelaskan apa yang berubah dan mengapa.
Bacaan terkait: Mengapa API bursa mengembalikan 403 atau 451 · Cara memperbaiki error Binance -1021 · Cara memeriksa apakah bursa down
Sumber
Binance · Batas · Bybit · Aturan batas laju · OKX · Dokumentasi API · MDN · 429 · Tentang Tickmark
Panduan lain
Apa itu funding rate pada perpetual futures kripto? Penjelasan sederhana
Funding rate adalah pembayaran rutin antara trader yang memegang sisi berlawanan pada kontrak perpetual futures. Kontrak ini ada karena perpetual tidak pernah jatuh tempo, sehingga perlu mekanisme lain untuk menjaga harganya tetap dekat dengan aset dasarnya. Saat rate positif, long membayar short; saat negatif, short membayar long. Bursa menetapkan rumusnya, tetapi di bursa-bursa besar uang itu berpindah antar trader.
Cara membandingkan funding rate antar bursa: penyelesaian 8 jam vs 4 jam
Anda tidak bisa membandingkan dua funding rate hanya dari persentasenya. Sebuah rate baru bermakna setelah Anda tahu seberapa sering dikenakan, apakah Anda long atau short, dan apakah kedua pembacaan menggambarkan kontrak yang sama pada saat yang sama. +0,01% yang sama berbiaya dua kali lipat per hari pada jadwal empat jam dibanding jadwal delapan jam, dan apa yang menjadi biaya long adalah pendapatan bagi short.
Apa arti funding rate negatif? Siapa membayar, dan apa yang tidak disampaikannya
Funding rate negatif berarti trader yang memegang posisi short membayar trader yang memegang posisi long pada penyelesaian berikutnya. Biasanya ini terjadi saat kontrak perpetual diperdagangkan di bawah harga indeksnya, yang sering mencerminkan shorting besar-besaran atau lindung nilai. Rate negatif tidak berarti harga akan segera turun atau naik, dan bukan pendapatan gratis bagi long, karena harga bisa bergerak melawan mereka jauh melebihi pembayarannya.
Cara mengubah funding rate menjadi APR, dan mengapa angkanya bisa menyesatkan
Untuk menyetahunkan funding rate, kalikan rate per penyelesaian dengan jumlah penyelesaian dalam sehari, lalu dengan 365. Rate 0,01% setiap delapan jam menjadi 0,01% × 3 × 365 = 10,95% setahun. Ini menempatkan kontrak dengan jadwal berbeda pada satu skala, sehingga bisa dibandingkan. Angka itu tidak memberi tahu berapa yang akan Anda peroleh atau bayar dalam setahun, karena mengasumsikan rate hari ini tidak pernah berubah.
Arbitrase funding rate: cara kerjanya dan apa yang menggerus keuntungan
Arbitrase funding rate berarti memegang dua posisi yang saling mengimbangi pada aset yang sama sehingga pergerakan harga kurang lebih saling meniadakan, sambil mengumpulkan pembayaran funding di satu sisi. Versi klasiknya membeli spot dan short perpetual. Versi kedua melakukan short perpetual di bursa dengan rate lebih tinggi dan long di bursa dengan rate lebih rendah. Strategi ini sering disebut bebas risiko. Padahal tidak. Risikonya hanya berbeda dari trade berarah biasa.
Harga mark vs harga terakhir vs harga indeks: mana yang melikuidasi Anda?
Perpetual futures menampilkan tiga harga yang mudah tertukar. Harga terakhir adalah tempat transaksi terbaru terjadi. Harga indeks adalah rata-rata harga spot di beberapa bursa. Harga mark adalah perkiraan bursa tentang nilai wajar kontrak, dan di bursa-bursa besar harga inilah yang menentukan keuntungan belum terealisasi dan apakah Anda dilikuidasi. Mengetahui fungsi tiap harga menjelaskan mengapa posisi bisa dilikuidasi meski grafik tidak pernah menyentuh level likuidasi Anda.
Berapa biaya market order sebenarnya: biaya transaksi, spread, dan slippage
Biaya di halaman tarif bursa hanyalah sebagian dari biaya market order. Sisanya berasal dari harga yang benar-benar Anda dapat, yang bergantung pada arah trade, ukuran order, dan kedalaman order book saat itu. Untuk membandingkan bursa secara adil, ukur harga isi rata-rata terhadap satu harga acuan, lalu tambahkan biaya transaksi, dan berhati-hatilah agar tidak menghitung spread dua kali.
Cara memperkirakan slippage dari kedalaman order book sebelum bertransaksi
Slippage adalah selisih antara harga yang Anda harapkan dan harga rata-rata yang benar-benar Anda dapat. Sebagian besar bisa diperkirakan sebelum menempatkan order, karena order book menunjukkan berapa yang tersedia di tiap harga. Jumlahkan tingkat di sisi yang akan Anda konsumsi sampai menutup ukuran Anda, hitung harga rata-rata, dan bandingkan dengan harga tengah. Perkiraan hanya sebaik potret asalnya, dan order book menipis pada saat Anda paling mungkin membutuhkannya.
Biaya maker dan taker: cara membandingkan biaya transaksi bursa kripto
Maker menambahkan order ke order book yang menunggu terisi. Taker mengisi terhadap order yang sudah ada di sana. Kebanyakan bursa mengenakan lebih banyak pada taker, karena maker menyediakan likuiditas yang menjadi lawan transaksi orang lain. Membandingkan bursa hanya dari biaya utama menyesatkan: Anda perlu tahu sisi mana yang biasanya Anda pakai, tingkat apa yang sebenarnya berlaku untuk volume Anda, dan bagaimana biaya itu dibanding slippage serta funding pada trade yang sama.
Cara memeriksa apakah bursa kripto sedang down: panduan langkah demi langkah
Saat bursa berhenti berfungsi bagi Anda, pertanyaan pertama adalah apakah bursa itu down untuk semua orang atau hanya untuk Anda. Biasanya bisa dijawab dalam beberapa menit: periksa halaman status bursa, periksa pengukuran independen, coba jaringan lain, dan uji API publik langsung. Setiap sumber melihat hal berbeda, jadi satu halaman hijau tidak membuktikan semuanya baik, dan satu permintaan gagal tidak membuktikan bursa down.
Apakah bursa benar-benar down? Cara membaca uptime API dan catatan insiden
Uptime menggambarkan porsi permintaan yang berhasil ke layanan tertentu, selama periode tertentu, dari rute jaringan tertentu. Uptime tidak memastikan Anda bisa menempatkan order, menarik dana, atau memercayakan aset pada suatu bursa. Angka seperti 99,9% hanya berguna jika Anda tahu apa yang diuji, dari mana, dan berapa lama, jadi panduan ini menjelaskan cara membaca detail itu di halaman kami dan di tempat lain.
Apa yang harus dilakukan saat bursa kripto down ketika Anda punya posisi terbuka
Jika bursa berhenti merespons saat Anda memegang posisi, tugas pertama adalah mencari tahu apa yang sebenarnya rusak, kedua jangan memperburuknya, dan ketiga mengurangi risiko lewat jalur apa pun yang masih berfungsi. Jangan terus mengirim ulang order yang sama, karena percobaan sebelumnya mungkin sudah berhasil. Periksa aplikasi seluler dan API sebagai jalur alternatif, pertimbangkan lindung nilai di tempat lain jika eksposur besar, dan catat kejadiannya jika nanti perlu diajukan.
Mengapa API bursa menolak timestamp: selisih jam dan kuotasi basi
Respons cepat bisa berisi kuotasi lama. Latensi pulang-pergi, selisih jam, dan umur kuotasi menggambarkan bagian berbeda dari suatu permintaan, dan mencampurnya bisa membuat ketidakcocokan jam tampak seperti umpan pasar yang terlambat. Panduan ini menjelaskan masing-masing dengan contoh, menunjukkan cara kami memperkirakannya, dan membahas yang harus dilakukan saat API bursa menolak permintaan Anda karena waktu.
Error Binance -1021 timestamp: penyebab dan cara memperbaikinya
Error API Binance -1021 INVALID_TIMESTAMP berarti timestamp pada permintaan bertanda tangan Anda berada di luar jendela yang diterima Binance. Pesannya biasanya Timestamp for this request is outside of the recvWindow atau was 1000ms ahead of the server's time. Dalam kebanyakan kasus jam Anda sendiri penyebabnya, jadi solusinya adalah menyinkronkannya, mengukur selisih terhadap waktu server Binance, dan menangani sisa jeda jaringan dengan benar. recvWindow lebih besar bisa menyembunyikan masalah, tetapi tidak boleh menjadi langkah pertama.
Mengapa API bursa mengembalikan 403 atau 451: blokir dan wilayah
403 berarti server memahami permintaan Anda dan menolak melaksanakannya. 451 berarti akses ditolak karena alasan hukum. Pada API bursa kripto, 403 bisa berupa firewall web, batas permintaan, kunci tanpa izin, atau blokir wilayah, jadi kodenya saja tidak menunjukkan yang mana. Isi respons, dokumentasi bursa, dan perbandingan dari jaringan lain biasanya menunjukkannya. Pembatasan nyata berlaku pada Anda karena suatu alasan, jadi respons yang benar adalah mencari tahu apakah layanan tersedia di tempat Anda.
Sebelum membuka akun bursa kripto di Indonesia: daftar cek
Sebelum membuka akun di bursa kripto, cek empat hal: apakah bursa itu boleh melayani orang di tempat Anda tinggal, apakah regulator di negara Anda memberinya izin, apakah situs di depan Anda adalah situs yang asli, dan bagaimana bursa itu berjalan belakangan ini. Mengisi formulir pendaftaran hanya butuh sepuluh menit. Memperbaiki pilihan yang salah bisa makan waktu berbulan-bulan, dan kadang tidak bisa diperbaiki sama sekali. Panduan ini membahas setiap pengecekan satu per satu, dengan Binance dan OKX sebagai contoh karena keduanya paling sering ditanyakan pembaca kami, serta menjelaskan kondisi di Indonesia pada November 2026.