Bot Taruhan dan API: Otomatisasi Tanpa Membuat Akun Anda Dibatasi

Apa sebenarnya yang dipisahkan aturan ini

Otomatisasi adalah satu dari beberapa jalur di dalam kumpulan metode taruhan profesional yang lebih luas yang dibahas situs ini, dan ini mendapat halamannya sendiri karena aturannya di sini lebih spesifik daripada sekadar "petaruh sharp memakai perangkat lunak". Singkatan forum memperlakukan "bot" sebagai satu hal: perangkat lunak yang menempatkan taruhan. Ketentuan Betfair lebih tepat. Klausul 12.1.4 mencantumkan, di antara aktivitas yang dianggapnya dicurigai, sebuah taruhan yang ditempatkan "otherwise than through the Account holder placing each Bet manually" (selain lewat pemegang akun yang menempatkan setiap Taruhan secara manual), yang jika dibaca sendirian akan menjerat setiap skrip yang pernah ditulis. Klausul ini tidak dibaca sendirian: klausul yang sama membawa pengecualiannya sendiri, dinyatakan untuk menghindari keraguan, bahwa taruhan yang ditempatkan "via the Application Programming Interface (API)" (lewat Application Programming Interface/API) tidak termasuk. Gabungkan kedua potongan ini dan pemisahannya jadi persis: sebuah skrip yang mengklik lewat situs web biasa adalah yang disasar klausul ini, dan sebuah skrip yang berbicara dengan API adalah pengecualian yang disebut klausul ini sendiri.

Catatan singkat: "bot" melakukan banyak tugas dalam kalimat itu, dan kata itu sebenarnya tidak pernah muncul dalam klausulnya. Pengacara Betfair menulis "otherwise than through the Account holder placing each Bet manually" sebagai gantinya, cara yang lebih panjang untuk mengatakan hal yang sama tetapi kalimat yang jauh lebih sulit dikutip salah. Baiklah, kembali ke apa artinya bagi Anda.

Jadi aturannya bukan "bot dilarang" dan bukan "bot boleh-boleh saja". Aturannya lebih sempit: sebuah skrip tidak resmi yang bekerja di situs web seperti sepasang tangan yang sangat cepat berada di dalam klausul soal aktivitas yang dicurigai, sementara logika yang sama yang terhubung ke API resmi berada di dalam pengecualian. Seseorang yang melakukan trading ladder dengan tangan sendiri dan sebuah skrip yang melakukan hal yang sama lewat API diperlakukan berbeda oleh dokumen yang sama, dan perbedaannya ada pada pintunya, bukan pada strategi di baliknya.

Apa yang harus diuji sebelum sebuah Live key didanai

Setiap orang yang membangun sebuah bot ingin langsung melompat ke menempatkan taruhan. Urutan yang jujur berjalan sebaliknya: buktikan dulu logikanya terhadap data yang sengaja dibuat lebih lambat daripada waktu nyata, pada nilai taruhan terkecil yang diizinkan tempat bertaruhnya, sebelum sebuah kunci berbayar atau sebuah bankroll yang serius berada di dekatnya sama sekali.

Rentang itu, satu detik pada yang terbaik dan sampai tiga menit pada yang terburuk, bukan kesalahan pembulatan yang bisa diabaikan begitu saja. Sebuah odds yang terakhir dilihat skrip sebagai wajar bisa sudah bergerak jauh melewatinya pada saat skrip itu bertindak, dan tidak ada sandbox yang melunakkan itu: dokumentasi Betfair sendiri menyatakan tidak ada test bed yang membiarkan siapa pun menguji tanpa memakai dana sungguhan. Setiap taruhan yang ditempatkan Delayed key adalah taruhan sungguhan dengan hasil sungguhan, itulah sebabnya nilai taruhan terkecil yang diizinkan tempat bertaruhnya adalah satu-satunya cara yang masuk akal untuk menjalankan tahap ini.

Sebuah hipotesis, dengan setiap angka direkayasa hanya untuk hitungannya. Katakanlah sebuah skrip mengamati sebuah odds di 2,10, memutuskan untuk melakukan back, dan API itu mengembalikan sebuah snapshot yang sudah berumur 180 detik tepat pada saat itu. Sebuah gol, sebuah kartu merah, atau sebuah penarikan pemain di menit akhir bisa terjadi dalam tiga menit, sehingga odds yang dikira skrip sedang di-back dan odds yang benar-benar ditawarkan saat order itu mendarat bisa menjadi dua angka yang berbeda. Tidak ada logika secerdas apa pun di hulu yang memperbaiki sebuah keputusan yang dibangun di atas informasi yang sudah basi; keterlambatan itu sendiri, bukan strategi di atasnya, adalah hal pertama yang patut diuji.

Tempat bertaruhnya hanya separuh gambaran; separuh lainnya adalah feed yang sebenarnya menjadi reaksi sebuah bot, dan sebuah skrip yang dibangun di atas riwayat yang tipis akan salah tembak kunci apa pun yang dipakainya. Periksa hitungannya dengan tangan di sebuah kalkulator sebelum mempercayai angka skrip itu sendiri, dan ingat bahwa komisi exchange masih dipotong dari taruhan apa pun yang menang; apa yang dilakukan itu pada angka bersih sebuah bot patut dibaca sebelum sebuah strategi dinyatakan sukses di atas kertas.

Batasan yang harus dirancang sekitar sebuah skrip

Semua ini bukan soal apakah otomatisasi diizinkan atau tidak. Ini soal batas atas yang diberlakukan API itu sendiri pada perilaku sebuah skrip, dinyatakan dalam angka yang jelas ketimbang dibiarkan menjadi tebakan. Empat di antaranya paling penting ketika sebuah skrip masih di atas meja gambar, dan, bersama jendela keterlambatan Delayed key di atas, semuanya adalah angka yang bisa direvisi Betfair; periksa ketentuan yang berlaku saat ini sebelum merancang kode produksi di sekitar angka mana pun dari ini.

• Batas 200 poin pada permintaan data market. Biayanya dijumlahkan di seluruh market dan jenis data yang diminta; melewati totalnya mengembalikan sebuah error ketimbang datanya.
• Batas 3 permintaan bersamaan pada panggilan order dan posisi. Memeriksa order saat ini, laba rugi, atau order yang sudah selesai lebih dari tiga kali sekaligus, sementara panggilan sebelumnya masih berjalan, ditolak ketimbang diantrekan.
• Batas 1.000 instruksi per detik untuk menempatkan, membatalkan, memperbarui, atau mengganti order. Itu mencakup seluruh akun di semua koneksi yang terbuka, bukan hanya satu skrip secara terpisah.
• Lockout 20 menit setelah terlalu banyak login yang gagal. Setiap percobaan login berikutnya otomatis ditolak selama periode itu, apa pun yang menyebabkan kegagalan sebelumnya.

Hipotesis kedua, dan yang sebenarnya paling sering menjerat orang. Sebuah skrip dengan bug pada penanganan login-nya gagal memperbarui sesinya tepat waktu dan mencoba lagi dalam sebuah loop yang rapat ketimbang mundur sejenak. Dua puluh menit kira-kira sama dengan satu babak sepak bola; memicu lockout itu saat kick-off dan skrip itu kehilangan lebih banyak bagian pertandingan daripada yang pernah ditangkapnya. Perbaikannya lebih membosankan daripada ceritanya: pertahankan sesinya, dan perlakukan login yang gagal sebagai alasan untuk berhenti, bukan untuk langsung mencoba lagi.