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

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 कंसोल में, कोटा और सिस्टम की सीमाएं पेज पर जाकर, कोटा में बदलाव करने का अनुरोध कर सकते हैं.

ज़्यादा जानने के लिए, ये लेख पढ़ें और वीडियो देखें:

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

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

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

ऐसा होने पर, ये तरीके अपनाएं:

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

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

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

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

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

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

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

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

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

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

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

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

सेवा खातों के साथ सही तरीके से कोटा बांटना

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

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

कोटा की सीमा को मैनेज करने की प्रोसेस की जांच करना

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

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

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

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

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

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

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

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

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

इस्तेमाल करने की सीमा का टाइप	क्वेरी की लागत
हर प्रोजेक्ट के लिए, हर मिनट	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 के एमसीपी के एपीआई का रेफ़रंस देखें.

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

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