एपीआई की सीमाएं और कोटा

Google Ads API, एपीआई ऑपरेशनों पर सीमाएं लागू करता है. जैसे, एक म्यूटेट अनुरोध में भेजे जा सकने वाले ऑपरेशनों की संख्या. यहां दी गई टेबल में, कुछ ज़रूरी सीमाओं और कोटे के बारे में खास जानकारी दी गई है.

अनुरोध का टाइप, सीमा, और गड़बड़ी का कोड
टेस्ट ऐक्सेस लेवल के साथ किए जा सकने वाले ऑपरेशन	टेस्ट खातों के लिए, हर दिन 15,000 एपीआई ऑपरेशन	RESOURCE_EXHAUSTED
एक्सप्लोरर ऐक्सेस लेवल के साथ किए जा सकने वाले ऑपरेशन	प्रोडक्शन खातों के लिए, हर दिन 2,880 एपीआई ऑपरेशन टेस्ट खातों के लिए, हर दिन 15,000 एपीआई ऑपरेशन	RESOURCE_EXHAUSTED
बेसिक ऐक्सेस लेवल के साथ किए जा सकने वाले ऑपरेशन	टेस्ट और प्रोडक्शन, दोनों तरह के खातों के लिए, हर दिन 15,000 एपीआई कार्रवाइयां	RESOURCE_EXHAUSTED
स्टैंडर्ड ऐक्सेस लेवल के साथ किए जा सकने वाले ऑपरेशन	टेस्ट और प्रोडक्शन, दोनों तरह के खातों के लिए, हर दिन एपीआई की अनलिमिटेड कार्रवाइयां	लागू नहीं
बदलाव के अनुरोध	हर अनुरोध में बदलाव करने की 10,000 कार्रवाइयां	TOO_MANY_MUTATE_OPERATIONS
प्लानिंग सेवा के अनुरोध	1 क्यूपीएस	RESOURCE_EXHAUSTED
Conversion Upload Service के अनुरोध	हर अनुरोध में 2,000 कन्वर्ज़न	TOO_MANY_CONVERSIONS_IN_REQUEST
बिलिंग और खाता बजट सेवा के अनुरोध	बदलाव के हर अनुरोध में एक कार्रवाई	TOO_MANY_MUTATE_OPERATIONS

एपीआई ऑपरेशन को रोज़ाना इस्तेमाल करने की सीमाएं

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

इन सीमाओं का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: RESOURCE_EXHAUSTED.

gRPC की सीमाएं

Google Ads API की सभी क्लाइंट लाइब्रेरी, अनुरोध और जवाब जनरेट करने के लिए gRPC का इस्तेमाल करती हैं. डिफ़ॉल्ट रूप से, gRPC में मैसेज का साइज़ 4 एमबी होता है. हालांकि, हमारी क्लाइंट लाइब्रेरी, मैसेज के ज़्यादा से ज़्यादा साइज़ को 64 एमबी पर सेट करती हैं, ताकि बेहतर तरीके से काम किया जा सके.

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

इस सीमा का उल्लंघन करने वाले अनुरोधों के लिए, GoogleAdsError जनरेट नहीं होगा. हालांकि, RESOURCE_EXHAUSTED (gRPC कोड 8 / एचटीटीपी 429) गड़बड़ी जनरेट होगी. gRPC गड़बड़ी के कोड और मैसेज की सूची देखें.

बदलाव के अनुरोध

उपयोगकर्ता के हर दिन के ऑपरेशन के कोटे में गिनती होने के अलावा, एक म्यूटेट अनुरोध में हर अनुरोध के लिए 10,000 से ज़्यादा म्यूटेट ऑपरेशन नहीं हो सकते. इस सीमा का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: TOO_MANY_MUTATE_OPERATIONS.

यहां कुछ सेवाओं और अनुरोधों के टाइप के लिए, अतिरिक्त सीमाएं और ज़रूरी बातें बताई गई हैं.

खोज के अनुरोध

Search या SearchStream अनुरोध को, उपयोगकर्ता के लिए तय किए गए रोज़ाना के ऑपरेशन कोटे के हिसाब से एक ऑपरेशन माना जाता है. एक SearchStream अनुरोध को एक एपीआई ऑपरेशन माना जाता है. भले ही, बैच की संख्या कितनी भी हो.

पेज वाले अनुरोध

पेज वाले अनुरोधों (उदाहरण के लिए, ऐसे अनुरोध जिनमें मान्य next_page_token शामिल है) को उपयोगकर्ता के रोज़ाना के ऑपरेशन कोटा में नहीं गिना जाता. हालांकि, अगर पेज नंबर बदलने के अनुरोध में इस्तेमाल किया गया पेज टोकन अमान्य है या उसकी समयसीमा खत्म हो गई है, तो एक अपवाद जनरेट होगा. साथ ही, इसे हर दिन के लिए तय किए गए कोटे में गिना जाएगा.

पेज नंबर डालने के बारे में ज़्यादा जानने के लिए, नतीजों के पेजों पर जाना लेख पढ़ें.

अन्य तरह के अनुरोध

Mutate, Search या SearchStream के अलावा किसी अन्य तरह के अनुरोध को, उपयोगकर्ता के रोज़ाना के ऑपरेशन कोटा के हिसाब से एक ऑपरेशन माना जाता है.

इस तरह के अनुरोधों के कुछ उदाहरण यहां दिए गए हैं:

• BatchJobService.ListBatchJobResults
• ConversionUploadService.UploadCallConversions
• ConversionUploadService.UploadClickConversions
• OfflineUserDataJobService.AddOfflineUserDataJobOperations
• OfflineUserDataJobService.CreateOfflineUserDataJob
• UserDataService.UploadUserData

ऐसे अनुरोध जिनसे एपीआई अपवाद मिलते हैं

GoogleAdsFailure के साथ अस्वीकार किए गए अनुरोधों को भी, उपयोगकर्ता के हर दिन के ऑपरेशन कोटे में गिना जाता है.

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

कीवर्ड प्लान करने की सेवा

लागत और जटिलता की वजह से, कीवर्ड प्लान करने की सेवा के लिए अनुरोध करने के इन तरीकों पर, अन्य तरह के अनुरोधों के मुकाबले अलग सीमाएं लागू होती हैं.

• हर सीआईडी के लिए, हर सेकंड में सिर्फ़ एक अनुरोध किया जा सकता है:

  • KeywordPlanIdeaService.GenerateKeywordIdeas
  • KeywordPlanIdeaService.GenerateKeywordHistoricalMetrics
  • KeywordPlanIdeaService.GenerateKeywordForecastMetrics

  इन सीमाओं का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: RESOURCE_EXHAUSTED.

• एक क्यूपीएस का मतलब है कि 60 सेकंड में 60 अनुरोध किए गए.

• हर सीआईडी के लिए, हर सेकंड में दो अनुरोध किए जा सकते हैं:

  • KeywordPlanIdeaService.GenerateAdGroupThemes

कीवर्ड प्लान बनाते समय, इन सीमाओं को ध्यान में रखें.

कीवर्ड प्लान ऑब्जेक्ट	ज़्यादा से ज़्यादा संख्या
हर खाते के लिए KeywordPlan	10,000
हर KeywordPlan के लिए KeywordPlanAdGroup	200
हर KeywordPlan के लिए KeywordPlanAdGroupKeyword	10,000
हर KeywordPlan के लिए KeywordPlanCampaignKeyword (नेगेटिव कीवर्ड)	1,000
हर KeywordPlan के लिए KeywordPlanCampaign	1

ऑडियंस के बारे में अहम जानकारी देने वाली सेवा

AudienceInsightsService में मौजूद इन तरीकों पर, कोटे की कुछ सीमाएं लागू होती हैं.

• हर सीआईडी के लिए, रोज़ाना करीब 200 अनुरोध किए जा सकते हैं:
  • AudienceInsightsService.GenerateAudienceCompositionInsights
  • AudienceInsightsService.GenerateSuggestedTargetingInsights
• हर Google Cloud प्रोजेक्ट के लिए, हर सेकंड में दो अनुरोध किए जा सकते हैं:
  • AudienceInsightsService.GenerateTargetingSuggestionMetrics

कन्वर्ज़न अपलोड करने की सेवा

• हर अनुरोध में, कॉल या क्लिक कन्वर्ज़न की संख्या 2,000 से ज़्यादा नहीं होनी चाहिए:

  • ConversionUploadService.UploadCallConversions
  • ConversionUploadService.UploadClickConversions

  इन सीमाओं का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: TOO_MANY_CONVERSIONS_IN_REQUEST.

ध्यान दें: 15 जून, 2026 से, ConversionUploadService.UploadClickConversions का इस्तेमाल नए उपयोगकर्ताओं के लिए नहीं किया जा सकेगा (NotAllowlistedError.CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE). कन्वर्ज़न अपलोड करने के लिए नए इंटिग्रेशन को Data Manager API का इस्तेमाल करना होगा.

कन्वर्ज़न में बदलाव करने से जुड़ी जानकारी अपलोड करने की सेवा

• हर अनुरोध के लिए, कन्वर्ज़न अडजस्टमेंट की संख्या 2,000 से ज़्यादा नहीं होनी चाहिए:

  • ConversionAdjustmentUploadService.UploadConversionAdjustments

  इन सीमाओं का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: TOO_MANY_ADJUSTMENTS_IN_REQUEST.

कन्वर्ज़न वैल्यू के नियम

• हर खाते के लिए, कन्वर्ज़न वैल्यू के लिए ज़्यादा से ज़्यादा 1,00,000 नियम बनाए जा सकते हैं.

  इस सीमा का उल्लंघन करने वाले अनुरोधों को ResourceCountLimitExceededError.ACCOUNT_LIMIT गड़बड़ी दिखाकर अस्वीकार कर दिया जाता है.

ध्यान दें: Google Ads API का इस्तेमाल करके बनाए गए कन्वर्ज़न वैल्यू के नियम सिर्फ़ तब लागू होते हैं, जब वे कन्वर्ज़न वैल्यू के नियम के ऐसे सेट का हिस्सा हों जिसमें conversion_value_rules फ़ील्ड में ConversionValueRule संसाधन के नाम शामिल हों और जिसका ConversionValueRuleSet स्टेटस ENABLED पर सेट हो. कन्वर्ज़न वैल्यू के वे नियम जो कन्वर्ज़न वैल्यू के किसी नियम सेट का हिस्सा नहीं हैं वे Google Ads के यूज़र इंटरफ़ेस (यूआई) में नहीं दिखते. इन्हें सिर्फ़ एपीआई का इस्तेमाल करके मैनेज किया जा सकता है.

अगर खाते के लिए, ConversionValueRuleSet में attachment_type की CUSTOMER पहले से मौजूद है, तो आपको नए कन्वर्ज़न वैल्यू के नियमों को उस सेट में जोड़ना होगा, ताकि वे चालू हो सकें. अगर कन्वर्ज़न वैल्यू के लिए ऐसा कोई नियम सेट मौजूद नहीं है, तो आपको एक नियम सेट बनाना होगा. साथ ही, उसमें कन्वर्ज़न वैल्यू के नियम जोड़ने होंगे. इसके लिए, नियम सेट बनाना लेख पढ़ें.

बिलिंग और खाते के बजट से जुड़ी सेवाएं

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

  इस सीमा का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: MUTATE_NOT_ALLOWED.

• बदलाव के अनुरोधों के लिए, सिर्फ़ 1 कार्रवाई की अनुमति है.

  इस सीमा का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: TOO_MANY_MUTATE_OPERATIONS.

• एक ही खाते के बजट (AccountBudget या AccountBudgetProposal) में बदलाव करने के बीच, कम से कम 12 घंटे का अंतर होना चाहिए. 12 घंटे से पहले बदलाव करने पर, डेटा को वापस नहीं लाया जा सकता. इस समस्या को सिर्फ़ आपके Google Ads खाते का प्रतिनिधि हल कर सकता है.

ग्राहक खातों के लिए न्योते

नए उपयोगकर्ताओं को मौजूदा क्लाइंट खातों में शामिल होने का न्योता, CustomerUserAccessInvitationService की मदद से भेजा जा सकता है. इस सुविधा से, अन्य उपयोगकर्ताओं को न्योते के ईमेल भेजे जाते हैं. इसलिए, इसका गलत इस्तेमाल किया जा सकता है. इसलिए, इसके इस्तेमाल पर ये पाबंदियां लागू होती हैं:

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

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

उपयोगकर्ता का डेटा

उपयोगकर्ता के डेटा को UserDataService और OfflineUserDataJobService की मदद से मैनेज किया जाता है.

ध्यान दें: 1 अप्रैल, 2026 से, Customer Match के लिए UserDataService और OfflineUserDataJobService का इस्तेमाल, नए उपयोगकर्ताओं (वापस आने वाले NotAllowlistedError.CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE) के लिए सीमित कर दिया गया है. नए Customer Match इंटिग्रेशन के लिए, Data Manager API का इस्तेमाल करना होगा.

create या remove ऑपरेशन में मौजूद हर UserData ऑब्जेक्ट, किसी एक असली उपयोगकर्ता से जुड़ा होता है. किसी एक UserData ऑब्जेक्ट में मौजूद user_identifiers फ़ील्ड में, ज़्यादा से ज़्यादा 20 आइडेंटिफ़ायर शामिल किए जा सकते हैं. एक UserData ऑब्जेक्ट में इस सीमा से ज़्यादा वैल्यू डालने पर, OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS या UserDataError.TOO_MANY_USER_IDENTIFIERS गड़बड़ी होगी.

20 से ज़्यादा आइडेंटिफ़ायर वाले उपयोगकर्ताओं को मैनेज करना

अगर किसी एक एंड-यूज़र के पास 20 से ज़्यादा ऐसे आइडेंटिफ़ायर हैं जिन्हें आपको अपलोड करना है, तो आपको इन आइडेंटिफ़ायर को कई UserData ऑब्जेक्ट में डिस्ट्रिब्यूट करना चाहिए. यह पक्का करने के लिए कि Google इन सभी आइडेंटिफ़ायर को एक ही उपयोगकर्ता से जोड़ सके, उस उपयोगकर्ता के हर UserData ऑब्जेक्ट में कम से कम एक जैसा user_identifier शामिल होना चाहिए. जैसे, एक जैसा hashed_email, hashed_phone_number या third_party_user_id. Google, शेयर किए गए इन आइडेंटिफ़ायर का इस्तेमाल करके, अलग-अलग UserData ऑपरेशंस से मिली जानकारी को सही एंड-यूज़र प्रोफ़ाइल से लिंक और मर्ज करता है.

अगर आपको हैश किए गए ईमेल या फ़ोन नंबर जैसी व्यक्तिगत पहचान से जुड़ी जानकारी पर भरोसा है, तो पक्का करें कि वे Google Ads API की ज़रूरी शर्तों (SHA-256, छोटे अक्षर, कोई खाली जगह नहीं) के मुताबिक नॉर्मलाइज़ और हैश किए गए हों. इससे लिंक करने में होने वाली गड़बड़ियों को रोका जा सकेगा.

उदाहरण के लिए, अगर किसी उपयोगकर्ता के पास 30 ईमेल पते हैं, तो एक जैसे third_party_user_id वाले दो UserData ऑब्जेक्ट भेजे जा सकते हैं. इसके लिए, पहले ऑब्जेक्ट में thirdPartyUserId वाले 1 से 19 तक के ईमेल पते और दूसरे ऑब्जेक्ट में thirdPartyUserId वाले 20 से 30 तक के ईमेल पते शामिल करें. ऐसा इसलिए, ताकि आइडेंटिफ़ायर की संख्या 20 से ज़्यादा न हो:

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_1" },
    // Hashed emails 2 through 18 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_19" }
  ]
}

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_20" },
    // Hashed emails 21 through 29 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_30" }
  ]
}

एक AddOfflineUserDataJobOperationsRequest में सभी कार्रवाइयों के लिए, user_identifiers की कुल सीमा 1,00,000 है. OfflineUserDataJob, कई AddOfflineUserDataJobOperationsRequest कॉल स्वीकार कर सकता है. हालांकि, हर जॉब के लिए ज़्यादा से ज़्यादा 10,00,000 कार्रवाइयां करने का सुझाव दिया जाता है. UploadUserDataRequest (UserDataService.UploadUserData) का इस्तेमाल करके सिंक्रोनस अपलोड के लिए, हर अनुरोध में ज़्यादा से ज़्यादा 10 कार्रवाइयां और पूरे अनुरोध में 100 user_identifiers शामिल की जा सकती हैं.

अन्य तरह की सीमाएं

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

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

GAQL क्वेरी करते समय, IN क्लॉज़ में ज़्यादा से ज़्यादा 20,000 आइटम हो सकते हैं. इस सीमा को पार करने पर, FILTER_HAS_TOO_MANY_VALUES गड़बड़ी का मैसेज दिखता है.