Skip to main content
/v1 API दो स्वतंत्र अनुरोध बजट लागू करता है। यदि दोनों में से कोई भी बजट समाप्त हो जाता है, तो अनुरोध अस्वीकार कर दिया जाता है। प्रति-key बजट key के साथ वहाँ भी लागू रहता है जहाँ उसका उपयोग किया जाता है। प्रति-IP बजट अप्रमाणित ट्रैफ़िक के लिए एकमात्र बजट है और प्रमाणित ट्रैफ़िक के लिए एक दूसरी सीमा है।
सीमाएँ प्रमाणीकरण से पहले लागू की जाती हैं, इसलिए अमान्य या अनुपस्थित क्रेडेंशियल वाले अनुरोध भी स्रोत बजट में गिने जाते हैं। सटीक संख्यात्मक बजट ऑपरेटर द्वारा कॉन्फ़िगर किए जाते हैं और बदल सकते हैं; नीचे दिया गया प्रतिक्रिया अनुबंध वह स्थिर इंटरफ़ेस है जिस पर निर्माण किया जाना चाहिए।
किसी भी Basic क्रेडेंशियल रूप से प्रमाणीकरण करें — देखें Quickstart (apikey:secret या secret:)। BASE को संगठन के क्षेत्रीय होस्ट पर सेट करें — देखें Regions।

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

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

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

1

Retry-After का पालन करें

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

बार-बार विफल होने पर घातांकीय बैकऑफ़ अपनाएँ

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

अपनी अनुरोध दर को सुचारु रखें

अचानक बढ़े हुए ट्रैफ़िक के बजाय स्थिर अनुरोध दर को प्राथमिकता दें। बल्क रीड के लिए, कम अनुरोधों में पूरे संग्रह को कवर करने हेतु अधिकतम पेज आकार (limit=500) का उपयोग करें — देखें pagination। जब कई सूची वॉक समानांतर चल रहे हों (उदाहरण के लिए Power BI टेबल), तो समवर्तिता संयमित रखें और Retry-After का पालन करें, ताकि अस्थायी 429 पूरे रिफ़्रेश को विफल न कर दे।
यह उदाहरण GET अनुरोध के लिए केवल 429 प्रतिक्रियाओं पर पुनः प्रयास करता है, अधिकतम पाँच प्रयासों के साथ और प्रयासों के बीच अधिकतम 60 सेकंड की प्रतीक्षा के साथ। यह अन्य त्रुटियों पर तुरंत रुक जाता है। नेटवर्क टाइमआउट कॉलर तक प्रसारित होते हैं। अपने वर्कलोड के अनुसार टाइमआउट और पुनः प्रयास बजट कॉन्फ़िगर करें। requests रीड टाइमआउट को डेटा प्राप्त करते समय अधिकतम निष्क्रिय समय के रूप में व्याख्यायित करता है, न कि समग्र समय-सीमा के रूप में। LIVING_SECURITY_API_KEY को अपने सीक्रेट मैनेजर से लोड करें। इस उदाहरण को चलाने से पहले requests इंस्टॉल करें। इसका उपयोग करने के लिए get_with_retry("/organization") को कॉल करें।
Python
इस लूप को किसी write ऑपरेशन के आसपास कॉपी न करें। write के बाद टाइमआउट का अर्थ यह हो सकता है कि कनेक्शन विफल होने से पहले सर्वर ने उसे कमिट कर दिया था। write को केवल तभी दोहराएँ जब उस ऑपरेशन का संदर्भ स्पष्ट रूप से idempotency का दस्तावेज़ीकरण करता हो, और वही key तथा पेलोड बनाए रखें। अन्यथा, पुनः प्रयास करने से पहले संसाधन की स्थिति का मिलान करें।

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

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