Skip to main content
/v1 API’si, birbirinden bağımsız iki istek bütçesi uygular. Bütçelerden biri tükenirse istek reddedilir. API anahtarı başına bütçe, anahtarın kullanıldığı her yerde anahtarı takip eder. IP başına bütçe, kimliği doğrulanmamış trafik için tek bütçedir ve kimliği doğrulanmış trafik için ikinci bir üst sınır işlevi görür.
Sınırlar kimlik doğrulamadan önce uygulanır; bu nedenle geçersiz veya eksik kimlik bilgileri içeren istekler de kaynak bütçesine sayılır. Kesin sayısal bütçeler operatör tarafından yapılandırılır ve değişebilir; aşağıdaki yanıt sözleşmesi, üzerine geliştirme yapılabilecek kararlı arayüzdür.
İki Basic kimlik bilgisi biçiminden biriyle kimlik doğrulaması yapın — bkz. Hızlı Başlangıç (apikey:secret veya secret:). BASE değerini kuruluşun bölgesel ana bilgisayarına ayarlayın — bkz. Bölgeler.

429 yanıtı

Bir bütçe tükendiğinde API, saniye cinsinden bir Retry-After başlığı ve standart problem-details gövdesi ile birlikte 429 Too Many Requests döndürür:
429 Too Many Requests
Yanıt, hangi bütçenin tükendiğini belirtmez. Her 429 yanıtına aynı şekilde yaklaşın: bekleyin, ardından yeniden deneyin.

429 yanıtlarını işleme

1

Retry-After değerine uyun

Yeniden denemeden önce Retry-After başlığındaki saniye sayısı kadar en az bekleyin. Daha erken yeniden denemek, yalnızca reddedilecek isteklerde bütçeyi yeniden tüketir.
2

Tekrarlanan durumlarda üstel geri çekilme uygulayın

Bir yeniden deneme yine reddedilirse geri çekilme süresini artırın ve paralel çalışanların eş zamanlı yeniden denememesi için rastgele jitter ekleyin. Sunucunun Retry-After değerini yerel bir sınıra uydurmak için asla kısaltmayın. Sunucu, yeniden deneme bütçenizin izin verdiğinden daha uzun süre beklemenizi isterse durun ve işi daha sonraya planlayın.
3

İstek hızınızı düzenli tutun

Ani yoğunluklar yerine sabit bir istek hızını tercih edin. Toplu okumalarda, koleksiyonu daha az istekle kapsamak için izin verilen en büyük sayfa boyutunu (limit=500) kullanın — bkz. sayfalama. Birden fazla liste taraması paralel çalıştığında (örneğin Power BI tabloları) eşzamanlılığı makul düzeyde tutun ve geçici bir 429 yanıtının tüm yenilemeyi başarısız kılmaması için Retry-After değerine uyun.
Bu örnek, bir GET isteği için yalnızca 429 yanıtlarını yeniden dener; en fazla beş deneme yapar ve denemeler arasında en fazla 60 saniye bekler. Diğer hatalarda hemen durur. Ağ zaman aşımları çağırana iletilir. Zaman aşımlarını ve yeniden deneme bütçelerini iş yükünüze uygun biçimde yapılandırın. requests, okuma zaman aşımını genel bir son tarih olarak değil, veri alınırken izin verilen en uzun boşta kalma süresi olarak yorumlar. LIVING_SECURITY_API_KEY değerini gizli anahtar yöneticinizden yükleyin. Bu örneği çalıştırmadan önce requests paketini yükleyin. Kullanmak için get_with_retry("/organization") çağrısını yapın.
Python
Bu döngüyü bir yazma işleminin etrafında kullanmayın. Bir yazma işleminden sonra oluşan zaman aşımı, sunucunun bağlantı kopmadan önce işlemi kaydettiği anlamına gelebilir. Bir yazma işlemini yalnızca ilgili işlemin başvuru belgesi idempotency özelliğini açıkça belgeliyorsa, aynı anahtarı ve aynı yükü koruyarak tekrarlayın. Aksi takdirde, yeniden denemeden önce kaynağın durumunu doğrulayıp eşitleyin.

Önerilen yenileme takvimi

Yenileme sıklığını anahtar bütçenize ve sayfa boyutuna göre belirleyin. Büyük bir koleksiyonun tam geçmiş yüklemesi tek seferlik bir maliyettir; düzenli yenilemelerde her çalıştırmanın bütçenin oldukça altında kalması için artımlı zaman aralıklarını tercih edin. limit=500 değerini her zaman açıkça ayarlayın — 25 olan varsayılan değer istek sayısını katlar.