Skip to main content
API /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.
Lakukan autentikasi dengan salah satu bentuk kredensial Basic — lihat Panduan Memulai (apikey:secret atau secret:). Atur BASE ke host regional organisasi — lihat Wilayah.

Respons 429

Ketika suatu anggaran habis, API mengembalikan 429 Too Many Requests dengan header Retry-After (dalam detik) dan isi problem-details standar:
429 Too Many Requests
Respons tidak menyebutkan anggaran mana yang habis. Perlakukan setiap 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.
Contoh ini hanya mencoba ulang respons 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
Jangan menyalin perulangan ini untuk operasi tulis. Timeout setelah operasi tulis dapat berarti server telah menyimpan perubahan tersebut sebelum koneksi gagal. Ulangi operasi tulis hanya jika referensi operasi tersebut secara eksplisit mendokumentasikan idempotensi, dengan mempertahankan kunci dan payload yang sama. Jika tidak, rekonsiliasi status sumber daya sebelum mencoba lagi.

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 atur limit=500 secara eksplisit — nilai default 25 melipatgandakan jumlah permintaan.