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

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 में एक की बढ़ोतरी होगी.
• 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 का कोटा ज़रूरी है. भले ही, कोई काम न किया गया हो.

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

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

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

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

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

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

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

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

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

Calendar MCP के कोटे

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

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

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

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

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

कैलेंडर एमसीपी टूलसेट के कोटे

यहां दी गई टेबल में, हर 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 के इस्तेमाल से जुड़ी सीमाओं से बचना