> ## 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

> Living Security Public API के लिए अनुरोध बजट, 429 प्रतिक्रिया अनुबंध, और Retry-After का उपयोग करके पुनः प्रयास कैसे करें।

`/v1` API दो स्वतंत्र अनुरोध बजट लागू करता है। यदि दोनों में से कोई भी बजट समाप्त हो जाता है, तो अनुरोध अस्वीकार कर दिया जाता है।

| बजट | लागू होने का क्षेत्र |
| - | - |
| प्रति API key | उस key को प्रस्तुत करने वाला प्रत्येक अनुरोध, चाहे वह किसी भी पते से आए |
| प्रति क्लाइंट IP | उस पते से आने वाला प्रत्येक अनुरोध, चाहे वह प्रमाणित हो या नहीं |

प्रति-key बजट key के साथ वहाँ भी लागू रहता है जहाँ उसका उपयोग किया जाता है। प्रति-IP बजट अप्रमाणित ट्रैफ़िक के लिए एकमात्र बजट है और प्रमाणित ट्रैफ़िक के लिए एक दूसरी सीमा है।

<Note>
  सीमाएँ प्रमाणीकरण से पहले लागू की जाती हैं, इसलिए अमान्य या अनुपस्थित क्रेडेंशियल वाले अनुरोध भी स्रोत बजट में गिने जाते हैं। सटीक संख्यात्मक बजट ऑपरेटर द्वारा कॉन्फ़िगर किए जाते हैं और बदल सकते हैं; नीचे दिया गया प्रतिक्रिया अनुबंध वह स्थिर इंटरफ़ेस है जिस पर निर्माण किया जाना चाहिए।
</Note>

किसी भी Basic क्रेडेंशियल रूप से प्रमाणीकरण करें — देखें
[Quickstart](/hi/developers/v1/quickstart) (`apikey:secret` या `secret:`)।
`BASE` को संगठन के क्षेत्रीय होस्ट पर सेट करें — देखें
[Regions](/hi/developers/v1/regions)।

## 429 प्रतिक्रिया

जब कोई बजट समाप्त हो जाता है, तो API `429 Too Many Requests` लौटाता है, जिसके साथ `Retry-After` हेडर (सेकंड में) और मानक problem-details बॉडी होती है:

```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
}
```

प्रतिक्रिया यह नहीं बताती कि कौन-सा बजट समाप्त हुआ। प्रत्येक `429` को एक ही तरह से संभालें: प्रतीक्षा करें, फिर पुनः प्रयास करें।

## 429 प्रतिक्रियाओं को संभालना

<Steps>
  <Step title="Retry-After का पालन करें">
    पुनः प्रयास करने से पहले `Retry-After` हेडर में दिए गए सेकंड की संख्या के बराबर कम से कम प्रतीक्षा करें। इससे पहले पुनः प्रयास करने पर केवल उन अनुरोधों पर बजट पुनः खर्च होता है जो अस्वीकार कर दिए जाएँगे।
  </Step>

  <Step title="बार-बार विफल होने पर घातांकीय बैकऑफ़ अपनाएँ">
    यदि कोई पुनः प्रयास फिर से अस्वीकार कर दिया जाता है, तो अपना बैकऑफ़ बढ़ाएँ और यादृच्छिक जिटर जोड़ें, ताकि समानांतर वर्कर एक साथ पुनः प्रयास न करें। स्थानीय सीमा में फिट करने के लिए सर्वर के `Retry-After` को कभी छोटा न करें। यदि सर्वर आपसे आपके पुनः प्रयास बजट की अनुमति से अधिक प्रतीक्षा करने को कहता है, तो रुक जाएँ और कार्य को बाद के लिए शेड्यूल करें।
  </Step>

  <Step title="अपनी अनुरोध दर को सुचारु रखें">
    अचानक बढ़े हुए ट्रैफ़िक के बजाय स्थिर अनुरोध दर को प्राथमिकता दें। बल्क रीड के लिए, कम अनुरोधों में पूरे संग्रह को कवर करने हेतु अधिकतम पेज आकार (`limit=500`) का उपयोग करें — देखें
    [pagination](/hi/developers/v1/pagination)। जब कई सूची वॉक समानांतर चल रहे हों (उदाहरण के लिए Power BI टेबल), तो समवर्तिता संयमित रखें और `Retry-After` का पालन करें, ताकि अस्थायी 429 पूरे रिफ़्रेश को विफल न कर दे।
  </Step>
</Steps>

यह उदाहरण **GET** अनुरोध के लिए केवल `429` प्रतिक्रियाओं पर पुनः प्रयास करता है, अधिकतम पाँच प्रयासों के साथ और प्रयासों के बीच अधिकतम 60 सेकंड की प्रतीक्षा के साथ। यह अन्य त्रुटियों पर तुरंत रुक जाता है। नेटवर्क टाइमआउट कॉलर तक प्रसारित होते हैं। अपने वर्कलोड के अनुसार टाइमआउट और पुनः प्रयास बजट कॉन्फ़िगर करें। `requests` रीड टाइमआउट को डेटा प्राप्त करते समय अधिकतम निष्क्रिय समय के रूप में व्याख्यायित करता है, न कि समग्र समय-सीमा के रूप में।

`LIVING_SECURITY_API_KEY` को अपने सीक्रेट मैनेजर से लोड करें। इस उदाहरण को चलाने से पहले `requests` इंस्टॉल करें। इसका उपयोग करने के लिए `get_with_retry("/organization")` को कॉल करें।

```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)
```

इस लूप को किसी write ऑपरेशन के आसपास कॉपी न करें। write के बाद टाइमआउट का अर्थ यह हो सकता है कि कनेक्शन विफल होने से पहले सर्वर ने उसे कमिट कर दिया था। write को केवल तभी दोहराएँ जब उस ऑपरेशन का संदर्भ स्पष्ट रूप से idempotency का दस्तावेज़ीकरण करता हो, और वही key तथा पेलोड बनाए रखें। अन्यथा, पुनः प्रयास करने से पहले संसाधन की स्थिति का मिलान करें।

## अनुशंसित रिफ़्रेश शेड्यूल

अपने रिफ़्रेश अंतराल का निर्धारण अपने key बजट और पेज आकार के आधार पर करें। किसी बड़े संग्रह का पूर्ण ऐतिहासिक लोड एक बार की लागत है; सामान्य स्थिति के रिफ़्रेश के लिए वृद्धिशील विंडो को प्राथमिकता दें, ताकि प्रत्येक रन बजट से काफ़ी नीचे रहे। `limit=500` को हमेशा स्पष्ट रूप से सेट करें — 25 का डिफ़ॉल्ट अनुरोधों की संख्या को कई गुना बढ़ा देता है।


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