हम फ़ॉर्म बनाने वालों को यह तय करने के लिए ज़्यादा कंट्रोल दे रहे हैं कि कौन जवाब दे सकता है. इसके लिए, हम जवाब देने वालों के लिए ज़्यादा कंट्रोल देने वाली सेटिंग लॉन्च कर रहे हैं. एपीआई का इस्तेमाल करके 30 जून, 2026 के बाद बनाए गए फ़ॉर्म, डिफ़ॉल्ट रूप से ड्राफ़्ट फ़ॉर्मैट में सेव होंगे. ज़्यादा जानने के लिए, Google Forms में एपीआई से जुड़े बदलाव लेख पढ़ें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Google Forms API एक शेयर की जाने वाली सेवा है. इसलिए, हम इस पर कोटा और सीमाएं लागू करते हैं, ताकि सभी उपयोगकर्ता इसका सही तरीके से इस्तेमाल कर सकें. साथ ही, Google Workspace सिस्टम की परफ़ॉर्मेंस को बेहतर बनाए रखा जा सके.

अगर आपने कोटा से ज़्यादा अनुरोध किए हैं, तो आम तौर पर आपको 429: Too many requests एचटीटीपी स्टेटस कोड वाला जवाब मिलेगा. अगर ऐसा होता है, तो आपको एक एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करना चाहिए और बाद में फिर से कोशिश करनी चाहिए. अगर आपने हर मिनट के लिए तय किए गए कोटा के तहत अनुरोध किए हैं, तो एक दिन में किए जाने वाले अनुरोधों की संख्या पर कोई पाबंदी नहीं है.

ध्यान दें: फ़ॉर्म वॉच के लिए, अतिरिक्त सीमाएं तय की गई हैं. ज़्यादा जानकारी के लिए, पुश नोटिफ़िकेशन सेट अप करना और पाना लेख पढ़ें.

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

कोटा

अनुरोध पढ़ना

हर प्रोजेक्ट के लिए हर दिन	असीमित
हर प्रोजेक्ट के लिए हर मिनट	975
हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट	390

अनुरोध पढ़ने के लिए ज़्यादा शुल्क वाले अनुरोध

(इनका इस्तेमाल, forms.responses.list अनुरोधों के लिए किया जाता है.)

हर प्रोजेक्ट के लिए हर दिन	असीमित
हर प्रोजेक्ट के लिए हर मिनट	450
हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट	180

अनुरोध लिखना

हर प्रोजेक्ट के लिए हर दिन	असीमित
हर प्रोजेक्ट के लिए हर मिनट	375
हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से हर मिनट	150

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

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

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

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

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

Google Forms 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 सेकंड में फिर से अनुरोध भेज सकता है. कुछ समय बाद, क्लाइंट को हमेशा के लिए फिर से अनुरोध भेजने से रोका जाना चाहिए.

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

कीमत

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

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

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

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

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