Skip to main content
/v1 API ikkita mustaqil so‘rovlar limitini qo‘llaydi. Agar limitlardan biri tugagan bo‘lsa, so‘rov rad etiladi. Kalit bo‘yicha limit kalit qayerda ishlatilishidan qat’i nazar unga ergashadi. IP manzil bo‘yicha limit autentifikatsiyasiz trafik uchun yagona limit hisoblanadi, autentifikatsiya qilingan trafik uchun esa ikkinchi yuqori chegara vazifasini bajaradi.
Limitlar autentifikatsiyadan oldin qo‘llanadi, shuning uchun noto‘g‘ri yoki yetishmayotgan hisob ma’lumotlari bilan yuborilgan so‘rovlar ham manba limitiga hisoblanadi. Aniq raqamli limitlar operator tomonidan sozlanadi va o‘zgarishi mumkin; quyidagi javob shartnomasi esa integratsiyani qurishda tayanish mumkin bo‘lgan barqaror interfeysdir.
Ikki Basic hisob ma’lumotlari shaklidan istalgan biri bilan autentifikatsiyadan o‘ting — Quickstart bo‘limiga qarang (apikey:secret yoki secret:). BASE qiymatini tashkilotning mintaqaviy hostiga o‘rnating — Regions bo‘limiga qarang.

429 javobi

Limit tugaganda API 429 Too Many Requests javobini, soniyalarda ifodalangan Retry-After sarlavhasi va standart problem-details tanasi bilan qaytaradi:
429 Too Many Requests
Javobda qaysi limit tugagani ko‘rsatilmaydi. Har bir 429 javobiga bir xil munosabatda bo‘ling: kuting, so‘ng qayta urinib ko‘ring.

429 javoblarini qayta ishlash

1

Retry-After qiymatiga rioya qiling

Qayta urinishdan oldin kamida Retry-After sarlavhasida ko‘rsatilgan soniyalar soni qadar kuting. Erta qayta urinish faqat baribir rad etiladigan so‘rovlarda limitni yana sarflaydi.
2

Takroriy holatlarda eksponensial kechiktirishdan foydalaning

Agar qayta urinish yana rad etilsa, kechikishni oshiring va parallel ishlovchilar bir vaqtda qayta urinmasligi uchun tasodifiy jitter qo‘shing. Mahalliy chekka moslash uchun serverning Retry-After qiymatini hech qachon qisqartirmang. Agar server sizdan qayta urinish limitingiz ruxsat etganidan uzoqroq kutishni so‘rasa, to‘xtang va ishni keyinroqqa rejalashtiring.
3

So‘rovlar tezligini tekislang

Keskin ko‘tarilishlar o‘rniga barqaror so‘rov tezligini afzal ko‘ring. Ommaviy o‘qish uchun to‘plamni kamroq so‘rov bilan qamrab olish maqsadida maksimal sahifa hajmidan (limit=500) foydalaning — pagination bo‘limiga qarang. Bir nechta ro‘yxatni o‘qish jarayoni parallel bajarilganda (masalan, Power BI jadvallari), parallellik darajasini o‘rtacha saqlang va vaqtinchalik 429 butun yangilanishni muvaffaqiyatsiz tugatmasligi uchun Retry-After qiymatiga rioya qiling.
Ushbu misol GET so‘rovi uchun faqat 429 javoblarida qayta urinadi, ko‘pi bilan beshta urinish va urinishlar orasida ko‘pi bilan 60 soniya kutish bilan. U boshqa xatolarda darhol to‘xtaydi. Tarmoq taym-autlari chaqiruvchiga uzatiladi. Taym-autlar va qayta urinish limitlarini ish yukingizga mos ravishda sozlang. requests o‘qish taym-autini umumiy muddat sifatida emas, ma’lumot qabul qilishdagi maksimal bo‘sh turish vaqti sifatida talqin qiladi. LIVING_SECURITY_API_KEY qiymatini maxfiy ma’lumotlar menejeridan yuklang. Ushbu misolni ishga tushirishdan oldin requests ni o‘rnating. Undan foydalanish uchun get_with_retry("/organization") ni chaqiring.
Python
Ushbu siklni yozish operatsiyasi atrofida nusxalamang. Yozishdan keyingi taym-aut server ulanish uzilishidan oldin uni bajarib bo‘lganini anglatishi mumkin. Yozish operatsiyasini faqat ushbu operatsiya ma’lumotnomasida idempotentlik aniq hujjatlashtirilgan hollardagina, bir xil kalit va bir xil yuklamani saqlagan holda takrorlang. Aks holda, qayta urinishdan oldin resurs holatini tekshirib, mosligini ta’minlang.

Tavsiya etilgan yangilanish jadvali

Yangilanish chastotasini kalitingiz limiti va sahifa hajmiga qarab belgilang. Katta to‘plamning to‘liq tarixiy yuklanishi bir martalik xarajat hisoblanadi; barqaror rejimdagi yangilanishlar uchun har bir ishga tushirish limitdan ancha past qolishi uchun inkremental oynalarni afzal ko‘ring. limit=500 qiymatini doim aniq belgilang — standart qiymat 25 so‘rovlar sonini ko‘paytiradi.