/v1 menerapkan dua anggaran permintaan yang independen. Suatu permintaan
ditolak jika salah satu anggaran telah habis.
Anggaran per kunci mengikuti kunci tersebut ke mana pun kunci itu digunakan. Anggaran per IP
merupakan satu-satunya anggaran untuk lalu lintas yang tidak terautentikasi dan menjadi batas kedua untuk
lalu lintas yang terautentikasi.
Batas diberlakukan sebelum autentikasi, sehingga permintaan dengan kredensial yang tidak valid atau
tidak ada juga dihitung terhadap anggaran sumber. Anggaran numerik yang tepat
dikonfigurasi oleh operator dan dapat berubah; kontrak respons di bawah ini
adalah antarmuka stabil yang dapat dijadikan acuan dalam pengembangan.
apikey:secret atau secret:).
Atur BASE ke host regional organisasi — lihat
Wilayah.
Respons 429
Ketika suatu anggaran habis, API mengembalikan429 Too Many Requests dengan header
Retry-After (dalam detik) dan isi problem-details standar:
429 Too Many Requests
429
dengan cara yang sama: tunggu, lalu coba lagi.
Menangani 429
1
Patuhi Retry-After
Tunggu setidaknya selama jumlah detik yang tercantum pada header
Retry-After sebelum
mencoba ulang. Mencoba ulang lebih awal hanya akan kembali menghabiskan anggaran pada permintaan yang akan
ditolak.2
Lakukan backoff eksponensial pada pengulangan
Jika percobaan ulang kembali ditolak, perpanjang backoff Anda dan tambahkan jitter acak
agar worker paralel tidak mencoba ulang secara bersamaan. Jangan pernah memperpendek
Retry-After dari server agar sesuai dengan batas
lokal. Jika server meminta Anda menunggu lebih lama daripada yang diizinkan oleh anggaran percobaan ulang Anda,
hentikan dan jadwalkan pekerjaan tersebut untuk nanti.3
Haluskan laju permintaan Anda
Utamakan laju permintaan yang stabil daripada lonjakan. Untuk pembacaan data dalam jumlah besar, gunakan ukuran
halaman maksimum (
limit=500) agar seluruh koleksi dapat dicakup dengan lebih sedikit permintaan — lihat
paginasi. Ketika beberapa penelusuran daftar berjalan
secara paralel (misalnya tabel Power BI), jaga konkurensi tetap moderat dan patuhi
Retry-After agar 429 yang bersifat sementara tidak menggagalkan seluruh proses penyegaran.429 untuk permintaan GET, dengan paling banyak
lima percobaan dan waktu tunggu paling lama 60 detik di antara percobaan. Contoh ini berhenti
segera pada kesalahan lainnya. Timeout jaringan diteruskan ke pemanggil. Konfigurasikan
timeout dan anggaran percobaan ulang sesuai dengan beban kerja Anda. requests menafsirkan read
timeout sebagai waktu idle maksimum saat menerima data, bukan batas waktu keseluruhan.
Muat LIVING_SECURITY_API_KEY dari secret manager Anda. Instal requests
sebelum menjalankan contoh ini. Panggil get_with_retry("/organization") untuk menggunakannya.
Python
Jadwal penyegaran yang direkomendasikan
Sesuaikan frekuensi penyegaran dengan anggaran kunci dan ukuran halaman Anda. Pemuatan riwayat lengkap dari koleksi besar hanya menimbulkan biaya satu kali; utamakan jendela inkremental untuk penyegaran kondisi stabil agar setiap proses tetap jauh di bawah anggaran. Selalu aturlimit=500 secara eksplisit — nilai default 25 melipatgandakan jumlah permintaan.
