इस्तेमाल करने की सीमा

Google Calendar API के लिए कोटा तय किया गया है, ताकि सभी उपयोगकर्ता इसका सही तरीके से इस्तेमाल कर सकें. Calendar API का इस्तेमाल करते समय, इन तीन अहम सीमाओं का ध्यान रखना ज़रूरी है:

• एपीआई के इस्तेमाल से जुड़े कोटा: ये कोटा, हर प्रोजेक्ट और हर उपयोगकर्ता के हिसाब से लागू होते हैं. ज़्यादा जानकारी के लिए, Calendar API के इस्तेमाल के कोटे के टाइप देखें.

• Google Calendar के इस्तेमाल की सामान्य सीमाएं: Google Calendar API, शेयर की जाने वाली एक सेवा है. Google Workspace सिस्टम की परफ़ॉर्मेंस को बेहतर बनाए रखने के लिए, इस सेवा के इस्तेमाल की कुछ सीमाएं तय की गई हैं. ज़्यादा जानकारी के लिए, Calendar के इस्तेमाल की सीमाओं से बचना लेख पढ़ें

• ऑपरेशनल लिमिट: इन सीमाओं को किसी भी समय सीमित किया जा सकता है. उदाहरण के लिए, अगर आपने एक ही कैलेंडर में लगातार कई इवेंट बनाए हैं.

Calendar API के कोटा

दो तरह के कोटा लागू किए जाते हैं:

• हर मिनट, हर प्रोजेक्ट के लिए: यह आपके Google Cloud प्रोजेक्ट से एक मिनट में किए जा सकने वाले अनुरोधों की संख्या है.

• हर उपयोगकर्ता के लिए, हर प्रोजेक्ट के हिसाब से हर मिनट में किए जा सकने वाले अनुरोधों की संख्या: यह आपके क्लाउड प्रोजेक्ट में, किसी एक उपयोगकर्ता की ओर से किए जा सकने वाले अनुरोधों की संख्या होती है. इस सीमा का मकसद, यह पक्का करने में आपकी मदद करना है कि आपके उपयोगकर्ताओं के बीच, इस्तेमाल का सही बंटवारा हो.

कोटा का हिसाब, स्लाइडिंग विंडो का इस्तेमाल करके हर मिनट लगाया जाता है. अगर एक मिनट में आपके कोटे से ज़्यादा ट्रैफ़िक आता है, तो अगले मिनट में अनुरोधों की संख्या सीमित कर दी जाएगी. इससे यह पक्का किया जा सकेगा कि आपका औसत इस्तेमाल, कोटे के अंदर ही रहे.

यहां दी गई टेबल में, इन सीमाओं के बारे में बताया गया है:

इस्तेमाल करने की सीमा का टाइप	सीमा
हर प्रोजेक्ट के लिए हर मिनट	10,000 अनुरोध
हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट	600 अनुरोध

रोज़ाना की बिलिंग सीमा

हर दिन हर प्रोजेक्ट के लिए तय की गई इस सीमा से यह पता चलता है कि आपका Google Cloud प्रोजेक्ट, शुल्क लागू होने से पहले 24 घंटे की अवधि में ज़्यादा से ज़्यादा कितने अनुरोध कर सकता है.

इस सीमा के अंदर इस्तेमाल करने पर, कोई अतिरिक्त शुल्क नहीं लिया जाता. साथ ही, आपके Google Cloud खाते से कोई शुल्क नहीं लिया जाता. बिलिंग की पूरी जानकारी, साल 2026 में बाद में शेयर की जाएगी. साथ ही, कोई भी बदलाव लागू होने से कम से कम 90 दिन पहले इसकी सूचना दी जाएगी.

हर रोज़ के खर्च की इस थ्रेशोल्ड सीमा को बढ़ाने का अनुरोध नहीं किया जा सकता.

इस टेबल में, सीमा के बारे में जानकारी दी गई है:

थ्रेशोल्ड की सीमा का टाइप	सीमा
हर दिन, हर प्रोजेक्ट के लिए	10,00,000 अनुरोध

ज़्यादा जानकारी के लिए, एजेंट टूल और एपीआई के लिए Google Workspace का स्टैंडर्ड मॉडल देखें.

समय के हिसाब से तय किए गए कोटे से जुड़ी गड़बड़ियां ठीक करना

समय से जुड़ी सभी गड़बड़ियों (X मिनट में ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़े और ट्रंकेटेड एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करे. इससे यह पक्का किया जा सकेगा कि आपके डिवाइसों पर ज़्यादा लोड न पड़े.

एक्स्पोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी को ठीक करने की एक स्टैंडर्ड रणनीति है. एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों के बीच इंतज़ार के समय को बढ़ाकर, अनुरोधों को फिर से भेजने की कोशिश करता है. यह समय, बैकऑफ़ के लिए तय किए गए ज़्यादा से ज़्यादा समय तक बढ़ाया जा सकता है. अगर अनुरोध अब भी पूरे नहीं हो पा रहे हैं, तो यह ज़रूरी है कि अनुरोधों के बीच का समय तब तक बढ़ाया जाए, जब तक कि अनुरोध पूरा न हो जाए.

एल्गोरिदम का उदाहरण

एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को एक्स्पोनेंशियल तरीके से फिर से भेजता है. इससे, अनुरोधों को फिर से भेजने के बीच इंतज़ार का समय बढ़ जाता है. यह समय, बैकऑफ़ के लिए तय किए गए ज़्यादा से ज़्यादा समय तक बढ़ सकता है. उदाहरण के लिए:

1. Google Calendar API को अनुरोध भेजें.
2. अगर अनुरोध पूरा नहीं होता है, तो 1 + random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करें.
3. अगर अनुरोध पूरा नहीं होता है, तो 2 + random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करें.
4. अगर अनुरोध पूरा नहीं होता है, तो 4 + random_number_milliseconds इंतज़ार करें और फिर से अनुरोध करें.
5. इसी तरह, maximum_backoff बार तक.
6. इंतज़ार करना और फिर से कोशिश करना जारी रखें. हालांकि, ऐसा तय संख्या तक ही करें. साथ ही, फिर से कोशिश करने के बीच इंतज़ार करने की अवधि को न बढ़ाएं.

कहां:

• इंतज़ार का समय min(((2^n)+random_number_milliseconds), maximum_backoff) है. हर बार (अनुरोध) के लिए, n में 1 की बढ़ोतरी की जाती है.
• random_number_milliseconds, मिलीसेकंड की कोई भी संख्या है. यह संख्या 1,000 से कम या इसके बराबर होती है. इससे उन मामलों से बचने में मदद मिलती है जिनमें कई क्लाइंट किसी स्थिति की वजह से सिंक हो जाते हैं और सभी एक साथ फिर से कोशिश करते हैं. इससे सिंक की गई वेव में अनुरोध भेजे जाते हैं. फिर से कोशिश करने के हर अनुरोध के बाद, random_number_milliseconds की वैल्यू का फिर से हिसाब लगाया जाता है.
• maximum_backoff आम तौर पर 32 या 64 सेकंड का होता है. सही वैल्यू, इस्तेमाल के उदाहरण पर निर्भर करती है.

maximum_backoff बार कोशिश करने के बाद भी, क्लाइंट फिर से कोशिश कर सकता है. इसके बाद, फिर से कोशिश करने पर, बैकऑफ़ टाइम को बढ़ाने की ज़रूरत नहीं होती. उदाहरण के लिए, अगर कोई क्लाइंट 64 सेकंड का maximum_backoff समय इस्तेमाल करता है, तो इस वैल्यू तक पहुंचने के बाद, क्लाइंट हर 64 सेकंड में फिर से कोशिश कर सकता है. एक समय के बाद, क्लाइंट को बार-बार कोशिश करने से रोका जाना चाहिए.

फिर से कोशिश करने के बीच का इंतज़ार का समय और फिर से कोशिश करने की संख्या, आपके इस्तेमाल के उदाहरण और नेटवर्क की स्थितियों पर निर्भर करती है.

कीमत

Google Calendar API का इस्तेमाल, बिना किसी शुल्क के किया जा सकता है. कोटा अनुरोध की सीमाओं को पार करने पर, साल 2026 के आखिर में आपके Google Cloud बिलिंग खाते से शुल्क लिया जाएगा. ज़्यादा जानकारी के लिए, एजेंट टूल और एपीआई के लिए Google Workspace का स्टैंडर्ड मॉडल देखें.

कोटा बढ़ाने का अनुरोध करना

अपने प्रोजेक्ट के संसाधनों के इस्तेमाल के आधार पर, कोटा में बदलाव करने का अनुरोध किया जा सकता है. सेवा खाते से किए गए एपीआई कॉल को, एक ही खाते से किए गए कॉल के तौर पर माना जाता है. कोटा में बदलाव करने के लिए आवेदन करने से, मंज़ूरी मिलने की गारंटी नहीं मिलती. कोटा बढ़ाने के ऐसे अनुरोधों को मंज़ूरी मिलने में ज़्यादा समय लग सकता है जिनमें कोटा की वैल्यू को काफ़ी ज़्यादा बढ़ाने की मांग की गई हो.

सभी प्रोजेक्ट के लिए कोटा एक जैसा नहीं होता. समय के साथ Google Cloud का इस्तेमाल बढ़ने पर, आपको कोटे की वैल्यू बढ़ाने की ज़रूरत पड़ सकती है. अगर आपको लगता है कि आने वाले समय में, आपके इस्तेमाल में काफ़ी बढ़ोतरी हो सकती है, तो Google Cloud console में कोटा और सिस्टम की सीमाएं पेज पर जाकर, कोटा में बदलाव करने का अनुरोध किया जा सकता है.

ज़्यादा जानने के लिए, ये लेख पढ़ें:

• कोटा अडजस्टमेंट के बारे में जानकारी
• अपने कोटे के इस्तेमाल और सीमाओं की जानकारी देखना
• कोटा बढ़ाने का अनुरोध करना

समस्या हल करें

अगर इनमें से कोई भी कोटा पूरा हो जाता है, तो अनुरोध संख्या सीमित कर दी जाती है. साथ ही, आपकी क्वेरी के जवाब में आपको 403 usageLimits स्टेटस कोड या 429 usageLimits स्टेटस कोड मिलता है.

अगर ऐसा होता है, तो ये तरीके आज़माए जा सकते हैं:

1. पक्का करें कि आपने सभी सबसे सही तरीकों का पालन किया हो: एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करें, ट्रैफ़िक पैटर्न को रैंडम तरीके से सेट करें, और पुश नोटिफ़िकेशन का इस्तेमाल करें.

2. अगर आपका प्रोजेक्ट बढ़ रहा है और आपके पास ज़्यादा उपयोगकर्ता हैं, तो कोटा बढ़ाने का अनुरोध किया जा सकता है.

3. अगर हर उपयोगकर्ता के लिए तय कोटा की सीमा पूरी हो जाती है, तो ये काम किए जा सकते हैं:

   • अगर सेवा खाते का इस्तेमाल किया जा रहा है, तो लोड को उपयोगकर्ताओं के बीच बांटें या इसे कई सेवा खातों के बीच बांटें.

   • हर उपयोगकर्ता के लिए तय किए गए कोटा को बढ़ाने का अनुरोध किया जा सकता है. हालांकि, आम तौर पर इसे डिफ़ॉल्ट वैल्यू से ज़्यादा बढ़ाने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि आपका ऐप्लिकेशन अन्य तरह की सीमाओं को पार कर सकता है. उदाहरण के लिए, Calendar के इस्तेमाल की सामान्य सीमाएं या ऑपरेशनल सीमाएं.

4. कोटा की सीमाओं की जांच करने के लिए, सिर्फ़ टेस्ट के लिए एक अलग प्रोजेक्ट रजिस्टर करें. इस प्रोजेक्ट का कॉन्फ़िगरेशन, आपके प्रोडक्शन प्रोजेक्ट जैसा होना चाहिए. ज़्यादा जानकारी के लिए, टेस्ट कोटा की सीमा को मैनेज करना लेख पढ़ें.

ट्रैफ़िक पैटर्न को किसी भी क्रम में लगाना

Calendar क्लाइंट में ट्रैफ़िक पैटर्न में अचानक बढ़ोतरी हो सकती है. ऐसा तब होता है, जब कई क्लाइंट एक ही समय पर कार्रवाइयां करते हैं. उदाहरण के लिए, Calendar क्लाइंट के लिए आधी रात को पूरा सिंक करना, एक आम गलत तरीका है. इससे, हर मिनट के लिए तय किया गया कोटा खत्म हो जाएगा. साथ ही, अनुरोध संख्या सीमित करने और बैकऑफ़ की स्थिति पैदा हो जाएगी.

इससे बचने के लिए, पक्का करें कि आपका ट्रैफ़िक पूरे दिन में फैला हो. अगर आपके क्लाइंट को रोज़ सिंक करना है, तो क्लाइंट को कोई भी समय तय करने के लिए कहें. यह समय हर क्लाइंट के लिए अलग होना चाहिए. अगर आपको नियमित तौर पर कोई कार्रवाई करनी है, तो इंटरवल को +/- 25% तक बदलें. इससे ट्रैफ़िक को ज़्यादा समान रूप से बांटा जा सकेगा और उपयोगकर्ताओं को बेहतर अनुभव मिलेगा.

पुश नोटिफ़िकेशन का इस्तेमाल करना

इसका इस्तेमाल आम तौर पर तब किया जाता है, जब उपयोगकर्ता के कैलेंडर में कोई बदलाव होने पर कोई कार्रवाई करनी हो. यहां एक एंटी-पैटर्न, हर कैलेंडर को बार-बार पोल करना है. इससे आपका पूरा कोटा बहुत जल्दी खत्म हो जाएगा. उदाहरण के लिए, अगर आपके ऐप्लिकेशन के 5,000 उपयोगकर्ता हैं और वह हर उपयोगकर्ता के कैलेंडर को हर मिनट पोल करता है, तो इसके लिए हर मिनट कम से कम 5,000 के कोटे की ज़रूरत होगी. भले ही, कोई काम न किया गया हो.

सर्वर-साइड ऐप्लिकेशन, पुश नोटिफ़िकेशन के लिए रजिस्टर कर सकते हैं. इससे हमें आपको सूचना देने की अनुमति मिलती है. ऐसा तब होता है, जब आपकी दिलचस्पी से जुड़ा कोई इवेंट होता है. इन्हें सेट अप करने के लिए ज़्यादा मेहनत करनी पड़ती है. हालांकि, इनसे आपके कोटे का ज़्यादा बेहतर तरीके से इस्तेमाल किया जा सकता है. साथ ही, उपयोगकर्ताओं को बेहतर अनुभव मिलता है. पक्का करें कि आपने वह eventType बताया हो जिसके लिए आपको सूचना चाहिए. ज़्यादा जानकारी के लिए, पुश नोटिफ़िकेशन लेख पढ़ें.

सेवा खातों के साथ सही तरीके से ऐलोकेशन

अगर आपका ऐप्लिकेशन डोमेन-वाइड डेलिगेशन का इस्तेमाल करके अनुरोध कर रहा है, तो डिफ़ॉल्ट रूप से सेवा खाते से "हर मिनट, हर उपयोगकर्ता, हर प्रोजेक्ट" के कोटे के हिसाब से शुल्क लिया जाता है. यह शुल्क उस उपयोगकर्ता से नहीं लिया जाता जिसकी पहचान का इस्तेमाल किया जा रहा है. इसका मतलब है कि सेवा खाते का कोटा खत्म हो सकता है और उस पर अनुरोध संख्या सीमित करने की सुविधा लागू हो सकती है. भले ही, वह कई उपयोगकर्ताओं के कैलेंडर पर काम कर रहा हो.

इससे बचने के लिए, quotaUser यूआरएल पैरामीटर (या x-goog-quota-user एचटीटीपी हेडर) का इस्तेमाल करके, कोई भी स्ट्रिंग (ज़्यादा से ज़्यादा 40 वर्ण) तय की जा सकती है. इससे हर उपयोगकर्ता की अलग से पहचान की जा सकती है. Calendar API, इस वैल्यू का इस्तेमाल सिर्फ़ कोटे का हिसाब लगाने के लिए करता है.

अलग-अलग उपयोगकर्ताओं के लिए, हर उपयोगकर्ता के हिसाब से अनुरोध की दर की सीमाएं लागू करने के लिए, quotaUser का इस्तेमाल किया जा सकता है. इसके लिए, आपके अनुरोधों को ये ज़रूरी शर्तें पूरी करनी होंगी:

• आईपी पते से जुड़ी पाबंदी वाला एपीआई पासकोड शामिल करें: key क्वेरी पैरामीटर में एपीआई पासकोड पास करें. साथ ही, उस पासकोड को आईपी पते से जुड़ी पाबंदियों के साथ कॉन्फ़िगर करें. इसके लिए, अपने बैकएंड सर्वर के सार्वजनिक आईपी पते बताएं. अगर एपीआई पासकोड को शामिल नहीं किया जाता है या आईपी पते से जुड़ी पाबंदियां कॉन्फ़िगर नहीं की जाती हैं, तो Calendar API, quotaUser को अनदेखा कर देता है. साथ ही, पुष्टि किए गए खाते (जैसे, सेवा खाता) से कोटा शुल्क लेता है.

• X-Goog-User-Project हेडर को शामिल न करें: quotaUser का इस्तेमाल करने वाले अनुरोधों पर, X-Goog-User-Project एचटीटीपी हेडर न भेजें. उपयोगकर्ता प्रोजेक्ट देने पर, कोटे के एट्रिब्यूशन के लिए एपीआई पासकोड बदल जाता है. इसलिए, Calendar API quotaUser को अनदेखा कर देता है.

ज़्यादा जानकारी के लिए, हर उपयोगकर्ता के लिए अनुरोधों की संख्या सीमित करना लेख पढ़ें.

कोटा की सीमा को मैनेज करने की सुविधा को टेस्ट करना

यह पक्का करने के लिए कि आपका ऐप्लिकेशन, कोटा की सीमाएं पूरी होने पर सही तरीके से काम करे (उदाहरण के लिए, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के ज़रिए) और आपके उपयोगकर्ताओं को किसी भी तरह की परेशानी न हो, हमारा सुझाव है कि आप अपने ऐप्लिकेशन को असल माहौल में टेस्ट करें.

हमारा सुझाव है कि आप Google Cloud Console में, सिर्फ़ टेस्ट के लिए एक अलग प्रोजेक्ट रजिस्टर करें. इसके बाद, OAuth के लिए सहमति देने वाली स्क्रीन को कॉन्फ़िगर करें. इससे, आपके असली ऐप्लिकेशन के इस्तेमाल में कोई रुकावट नहीं आएगी. साथ ही, यह आपके प्रोडक्शन प्रोजेक्ट की तरह ही काम करेगा. इसके बाद, इस प्रोजेक्ट के लिए कोटा की सीमाएं कम सेट की जा सकती हैं. साथ ही, अपने ऐप्लिकेशन के काम करने के तरीके पर नज़र रखी जा सकती है.

Calendar के एमसीपी सर्वर का कोटा

Calendar का एमसीपी सर्वर, क्वेरी की लागत तय करने वाली मेट्रिक का इस्तेमाल करता है. यहां दी गई टेबल में, Calendar के एमसीपी सर्वर के हर तरीके के लिए, क्वेरी की लागत की जानकारी दी गई है. यह जानकारी सेक्शन के हिसाब से दी गई है:

Calendar के लिए एमसीपी कोटा

दो तरह के कोटा लागू किए जाते हैं:

• हर मिनट, हर प्रोजेक्ट के लिए: यह आपके Google Cloud प्रोजेक्ट के लिए, एक मिनट की क्वेरी की लागत है.

• हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट में किए जा सकने वाले अनुरोधों की संख्या: यह आपके Google Cloud प्रोजेक्ट के लिए, एक मिनट में की जाने वाली क्वेरी की कीमत है. इसे कोई भी उपयोगकर्ता इस्तेमाल कर सकता है.

यहां दी गई टेबल में, इन कोटा के बारे में बताया गया है:

इस्तेमाल करने की सीमा का टाइप	क्वेरी की लागत
हर प्रोजेक्ट के लिए हर मिनट	10,000
हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट	600

Calendar के एमसीपी टूलसेट के कोटा

इस टेबल में, हर calendarmcp.googleapis.com टूलसेट के लिए क्वेरी की लागत की जानकारी दी गई है:

एंडपॉइंट	टूल	क्वेरी की लागत
/mcp/v1	create_event	1
	delete_event	10
	get_event	1
	list_events	1
	respond_to_event	1
	search_events	1
	update_event	1
	suggest_time	1
	list_calendars	1

ज़्यादा जानकारी के लिए, Calendar MCP API का रेफ़रंस देखें.

मिलते-जुलते विषय

• एक साथ कई अनुरोध भेजना
• परफ़ॉर्मेंस से जुड़ी सलाह
• Calendar के इस्तेमाल की सीमाओं से बचना