> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate Limits (So‘rovlar chekloví)

> Living Security Public API uchun so‘rovlar limitlari, 429 javob shartnomasi va Retry-After yordamida qayta urinish tartibi.

`/v1` API ikkita mustaqil so‘rovlar limitini qo‘llaydi. Agar limitlardan biri tugagan bo‘lsa, so‘rov rad etiladi.

| Limit | Qo‘llanilish doirasi |
| - | - |
| Har bir API kalit uchun | Ushbu kalitni taqdim etgan har qanday so‘rov, istalgan manzildan |
| Har bir mijoz IP manzili uchun | Ushbu manzildan kelgan har qanday so‘rov, autentifikatsiya qilingan yoki qilinmaganidan qat’i nazar |

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.

<Note>
  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.
</Note>

Ikki Basic hisob ma’lumotlari shaklidan istalgan biri bilan autentifikatsiyadan o‘ting — [Quickstart](/uz/developers/v1/quickstart) bo‘limiga qarang (`apikey:secret` yoki `secret:`).
`BASE` qiymatini tashkilotning mintaqaviy hostiga o‘rnating — [Regions](/uz/developers/v1/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:

```json 429 Too Many Requests theme={null}
{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/rate_limited",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Rate limit exceeded. Retry after the Retry-After interval.",
  "code": "rate_limited",
  "request_id": "req_...",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/rate_limited",
  "retryable": true
}
```

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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](/uz/developers/v1/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.
  </Step>
</Steps>

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 Python theme={null}
import os
import random
import time
import requests

# US: BASE = "https://api.us-east-1.livingsecurity.ai/v1"
BASE = "https://api.eu-west-1.livingsecurity.ai/v1"
AUTH = ("apikey", os.environ["LIVING_SECURITY_API_KEY"])

def get_with_retry(path, params=None, max_attempts=5):
    if not 1 <= max_attempts <= 5:
        raise ValueError("max_attempts must be between 1 and 5")
    for attempt in range(max_attempts):
        response = requests.get(
            f"{BASE}{path}", auth=AUTH, params=params,
            headers={"Living-Security-Version": "2026-07-01"},
            timeout=(5, 30), allow_redirects=False,
        )
        if response.status_code != 429:
            response.raise_for_status()
            if not 200 <= response.status_code < 300:
                raise RuntimeError("Unexpected redirect; check your regional API URL")
            return response

        # The API returns Retry-After as a whole number of seconds.
        raw_wait = response.headers.get("Retry-After", "")
        request_id = response.headers.get("Request-Id", "unknown")
        response.close()
        if attempt == max_attempts - 1:
            raise RuntimeError(f"Retry budget exhausted; request_id={request_id}")
        if not raw_wait.isascii() or not raw_wait.isdigit() or len(raw_wait) > 6:
            raise RuntimeError(f"Invalid Retry-After; request_id={request_id}")

        wait = max(int(raw_wait), min(2 ** attempt, 30))
        delay = wait + random.uniform(0, 1)
        if delay > 60:
            raise RuntimeError(f"Retry-After exceeds wait budget; request_id={request_id}")
        time.sleep(delay)
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.