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

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

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

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

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

Calendar API के कोटा

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

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

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

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

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

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

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

हर दिन हर प्रोजेक्ट के लिए तय की गई इस सीमा से पता चलता है कि आपका क्लाउड प्रोजेक्ट, 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. अगर हर उपयोगकर्ता के लिए तय की गई कोटा सीमाएं पूरी हो जाती हैं, तो ये काम किए जा सकते हैं:

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

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

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

ट्रैफ़िक पैटर्न को रैंडम करना

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

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

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

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

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

सेवा खातों के साथ सही तरीके से संसाधन असाइन करना

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

quotaUser यूआरएल पैरामीटर या x-goog-quota-user एचटीटीपी हैडर का इस्तेमाल करके, यह बताया जा सकता है कि किस उपयोगकर्ता से शुल्क लिया गया है. Google, इस पैरामीटर का इस्तेमाल सिर्फ़ कोटे का हिसाब लगाने के लिए करता है. ज़्यादा जानकारी के लिए, हर उपयोगकर्ता के लिए अनुरोधों की संख्या सीमित करना लेख पढ़ें.

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

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

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

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

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

Calendar MCP के कोटे

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

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

  • हर उपयोगकर्ता के लिए, हर प्रोजेक्ट के हिसाब से हर मिनट का शुल्क: यह क्वेरी का वह शुल्क है जो आपके क्लाउड प्रोजेक्ट में मौजूद कोई भी उपयोगकर्ता, एक मिनट में चुका सकता है.

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

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

Calendar MCP टूलसेट के कोटे

यहां दी गई टेबल में, हर 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 का रेफ़रंस देखें.