Gmail API के इस्तेमाल की सीमाएं होती हैं. इन सीमाओं से, एपीआई के तरीकों को कॉल करने की दर सीमित हो जाती है. सीमाओं को कोटा यूनिट के हिसाब से तय किया जाता है. यह माप की एक ऐसी इकाई है जो Gmail के संसाधनों के इस्तेमाल को दिखाती है.
Gmail API के कोटे
दो तरह के कोटे लागू किए जाते हैं:
प्रोजेक्ट के हिसाब से हर मिनट: यह कोटा यूनिट की वह संख्या है जिसका इस्तेमाल आपका Google Cloud प्रोजेक्ट एक मिनट में कर सकता है.
प्रोजेक्ट के हिसाब से हर उपयोगकर्ता के लिए हर मिनट: यह कोटा यूनिट की वह संख्या है जिसका इस्तेमाल कोई भी उपयोगकर्ता, आपके क्लाउड प्रोजेक्ट में एक मिनट में कर सकता है. इस सीमा का मकसद, यह पक्का करना है कि आपके उपयोगकर्ताओं के बीच, संसाधनों का इस्तेमाल सही तरीके से हो.
नीचे दी गई टेबल में, इन सीमाओं के बारे में जानकारी दी गई है:
| इस्तेमाल की सीमा का टाइप | सीमा |
|---|---|
| प्रोजेक्ट के हिसाब से हर मिनट | 12,00,000 कोटा यूनिट |
| प्रोजेक्ट के हिसाब से हर उपयोगकर्ता के लिए हर मिनट | 6,000 कोटा यूनिट |
सीमा से जुड़ी गड़बड़ियों को ठीक करने के बारे में जानकारी के लिए, गड़बड़ियां ठीक करना लेख पढ़ें.
बिलिंग की रोज़ की सीमा
प्रोजेक्ट के हिसाब से हर दिन की यह सीमा, कोटा यूनिट की वह ज़्यादा से ज़्यादा संख्या तय करती है जिसका इस्तेमाल आपका Google Cloud प्रोजेक्ट, 24 घंटे की अवधि में कर सकता है. इसके बाद, शुल्क लागू होते हैं.
इस सीमा के तहत इस्तेमाल करने पर, कोई अतिरिक्त शुल्क नहीं लगता. साथ ही, आपके Google Cloud खाते से कोई शुल्क नहीं काटा जाता. बिलिंग की पूरी जानकारी, 2026 में शेयर की जाएगी. साथ ही, किसी भी बदलाव के लागू होने से कम से कम 90 दिन पहले सूचना दी जाएगी.
रोज़ की इस सीमा को बढ़ाने का अनुरोध नहीं किया जा सकता.
नीचे दी गई टेबल में, इस सीमा के बारे में जानकारी दी गई है:
| सीमा का टाइप | सीमा |
|---|---|
| प्रोजेक्ट के हिसाब से हर दिन | 8,00,00,000 कोटा यूनिट |
ज़्यादा जानकारी के लिए, एजेंट टूल और एपीआई के लिए Google Workspace का स्टैंडर्ड मॉडल लेख पढ़ें.
हर तरीके के लिए कोटा का इस्तेमाल
हर अनुरोध के लिए, इस्तेमाल की जाने वाली कोटा यूनिट की संख्या, कॉल किए गए तरीके के हिसाब से अलग-अलग होती है. नीचे दी गई टेबल में, हर तरीके के लिए इस्तेमाल की जाने वाली कोटा यूनिट की जानकारी दी गई है:
| तरीका | कोटा यूनिट |
|---|---|
drafts.create |
10 |
drafts.delete |
10 |
drafts.get |
20 |
drafts.list |
5 |
drafts.send |
100 |
drafts.update |
15 |
getProfile |
1 |
history.list |
2 |
labels.create |
5 |
labels.delete |
5 |
labels.get |
1 |
labels.list |
1 |
labels.update |
5 |
messages.attachments.get |
20 |
messages.batchDelete |
50 |
messages.batchModify |
50 |
messages.delete |
10 |
messages.get |
20 |
messages.import |
25 |
messages.insert |
25 |
messages.list |
5 |
messages.modify |
5 |
messages.send |
100 |
messages.trash |
20 |
messages.untrash |
5 |
settings.delegates.create |
100 |
settings.delegates.delete |
5 |
settings.delegates.get |
1 |
settings.delegates.list |
1 |
settings.filters.create |
5 |
settings.filters.delete |
5 |
settings.filters.get |
1 |
settings.filters.list |
1 |
settings.forwardingAddresses.create |
100 |
settings.forwardingAddresses.delete |
5 |
settings.forwardingAddresses.get |
1 |
settings.forwardingAddresses.list |
1 |
settings.getAutoForwarding |
1 |
settings.getImap |
1 |
settings.getPop |
1 |
settings.getVacation |
1 |
settings.sendAs.create |
100 |
settings.sendAs.delete |
5 |
settings.sendAs.get |
1 |
settings.sendAs.list |
1 |
settings.sendAs.update |
100 |
settings.sendAs.verify |
100 |
settings.updateAutoForwarding |
5 |
settings.updateImap |
5 |
settings.updatePop |
100 |
settings.updateVacation |
5 |
stop |
50 |
threads.delete |
20 |
threads.get |
40 |
threads.list |
10 |
threads.modify |
10 |
threads.trash |
20 |
threads.untrash |
10 |
watch |
100 |
Gmail API का इस्तेमाल करते समय, हर ईमेल मैसेज के लिए 500 पाने वालों की सीमा भी होती है.
समय के हिसाब से तय किए गए कोटे से जुड़ी गड़बड़ियां ठीक करना
समय के हिसाब से तय की गई सभी गड़बड़ियों (हर X मिनट में ज़्यादा से ज़्यादा N अनुरोध) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले. साथ ही, यह पक्का करने के लिए कि आपके डिवाइस ज़्यादा लोड न करें, एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करें.
एक्सपोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी ठीक करने की एक स्टैंडर्ड रणनीति है. एक एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों के बीच इंतज़ार का समय तेज़ी से बढ़ाकर, अनुरोधों को फिर से भेजता है. यह तब तक किया जाता है, जब तक कि बैकऑफ़ का समय ज़्यादा से ज़्यादा न हो जाए. अगर अनुरोध अब भी पूरे नहीं होते हैं, तो यह ज़रूरी है कि अनुरोध के पूरे होने तक, अनुरोधों के बीच का समय बढ़ता रहे.
एल्गोरिदम का उदाहरण
एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम, अनुरोधों को तेज़ी से फिर से भेजता है. साथ ही, यह तब तक किया जाता है, जब तक कि बैकऑफ़ का समय ज़्यादा से ज़्यादा न हो जाए. उदाहरण के लिए:
- Gmail API को कोई अनुरोध भेजें.
- अगर अनुरोध पूरा नहीं होता है, तो 1 +
random_number_millisecondsतक इंतज़ार करें और अनुरोध को फिर से भेजें. - अगर अनुरोध पूरा नहीं होता है, तो 2 +
random_number_millisecondsतक इंतज़ार करें और अनुरोध को फिर से भेजें. - अगर अनुरोध पूरा नहीं होता है, तो 4 +
random_number_millisecondsतक इंतज़ार करें और अनुरोध को फिर से भेजें. - इसी तरह,
maximum_backoffसमय तक इंतज़ार करें और अनुरोध को फिर से भेजें. - अनुरोध को फिर से भेजने की कुछ तय सीमा तक इंतज़ार करें और अनुरोध को फिर से भेजें. हालांकि, अनुरोध को फिर से भेजने के बीच इंतज़ार की अवधि न बढ़ाएं.
कहां:
- इंतज़ार का समय
min(((2^n)+random_number_milliseconds), maximum_backoff)है. हर बार (अनुरोध) के लिए,nकी वैल्यू 1 से बढ़ जाती है. random_number_millisecondsमिलीसेकंड की एक ऐसी रैंडम संख्या है जो 1,000 से कम या उसके बराबर होती है. इससे, ऐसी स्थितियों से बचने में मदद मिलती है जिनमें कई क्लाइंट किसी स्थिति के हिसाब से सिंक हो जाते हैं और सभी एक साथ अनुरोध भेजते हैं. अनुरोध को फिर से भेजने के हर अनुरोध के बाद,random_number_millisecondsकी वैल्यू फिर से कैलकुलेट की जाती है.maximum_backoffआम तौर पर 32 या 64 सेकंड होता है. सही वैल्यू इस्तेमाल के उदाहरण पर निर्भर करती है.
maximum_backoff समय पूरा होने के बाद, क्लाइंट अनुरोध को फिर से भेज सकता है.
इसके बाद, अनुरोध को फिर से भेजने के लिए, बैकऑफ़ का समय बढ़ाने की ज़रूरत नहीं होती. उदाहरण के
लिए, अगर कोई क्लाइंट maximum_backoff के लिए 64 सेकंड का समय इस्तेमाल करता है, तो इस वैल्यू तक पहुंचने के
बाद, क्लाइंट हर 64 सेकंड में अनुरोध को फिर से भेज सकता है. कुछ समय बाद,
क्लाइंट को हमेशा के लिए अनुरोध को फिर से भेजने से रोका जाना चाहिए.
अनुरोध को फिर से भेजने के बीच इंतज़ार का समय और अनुरोध को फिर से भेजने की संख्या, आपके इस्तेमाल के उदाहरण और नेटवर्क की स्थितियों पर निर्भर करती है.
कीमत
Gmail API का स्टैंडर्ड इस्तेमाल, बिना किसी अतिरिक्त शुल्क के किया जा सकता है. कोटे के अनुरोध की सीमाओं से ज़्यादा इस्तेमाल करने पर, 2026 में आपके Google Cloud बिलिंग खाते से शुल्क काटे जाएंगे. ज़्यादा जानकारी के लिए, एजेंट टूल और एपीआई के लिए Google Workspace का स्टैंडर्ड मॉडल लेख पढ़ें.
कोटा बढ़ाने का अनुरोध करना
अपने प्रोजेक्ट के संसाधन के इस्तेमाल के हिसाब से, आपको कोटा में बदलाव करने का अनुरोध करना पड़ सकता है. सेवा खाते से किए गए एपीआई कॉल को, एक खाते का इस्तेमाल माना जाता है. कोटा में बदलाव के लिए आवेदन करने से, मंज़ूरी मिलने की गारंटी नहीं मिलती. कोटा में बदलाव के ऐसे अनुरोधों को मंज़ूरी मिलने में ज़्यादा समय लग सकता है जिनसे कोटा की वैल्यू में काफ़ी बढ़ोतरी हो सकती है.
सभी प्रोजेक्ट के लिए, कोटे एक जैसे नहीं होते. समय के साथ-साथ, Google Cloud का इस्तेमाल बढ़ने पर, आपको कोटे की वैल्यू बढ़ाने की ज़रूरत पड़ सकती है. अगर आपको लगता है कि आने वाले समय में, इस्तेमाल में काफ़ी बढ़ोतरी होगी, तो Google Cloud कंसोल में, कोटा और सिस्टम की सीमाएं पेज पर जाकर, कोटा में बदलाव करने का अनुरोध किया जा सकता है.
ज़्यादा जानने के लिए, ये संसाधन देखें:
- कोटा में बदलाव के बारे में जानकारी
- कोटे के इस्तेमाल और सीमाओं की जानकारी देखना
- कोटे की सीमा बढ़ाने का अनुरोध करना
मिलते-जुलते विषय
- परफ़ॉर्मेंस बेहतर बनाना
- मेल भेजने और पाने की सीमाएं
- Google Workspace में Gmail से ईमेल भेजने की सीमाएं