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

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
कन्वर्ज़न अपलोड सेवा के अनुरोध	हर अनुरोध के लिए, 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
KeywordPlanAdGroup हर KeywordPlan के लिए	200
KeywordPlanAdGroupKeyword हर KeywordPlan के लिए	10,000
KeywordPlanCampaignKeyword (नेगेटिव कीवर्ड) हर KeywordPlan के लिए	1,000
KeywordPlanCampaign हर KeywordPlan के लिए	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 का इस्तेमाल करके बनाए गए कन्वर्ज़न वैल्यू के नियम, सिर्फ़ तब चालू होते हैं, जब वे कन्वर्ज़न वैल्यू के नियम सेट का हिस्सा हों. इस सेट के ConversionValueRule संसाधन के नाम, इसके conversion_value_rules फ़ील्ड में शामिल होते हैं. साथ ही, ConversionValueRuleSet की स्थिति ENABLED पर सेट होती है. कन्वर्ज़न वैल्यू के ऐसे नियम जो कन्वर्ज़न वैल्यू के किसी नियम सेट का हिस्सा नहीं होते हैं, वे Google Ads के यूज़र इंटरफ़ेस (यूआई) में नहीं दिखते. इन्हें सिर्फ़ एपीआई का इस्तेमाल करके मैनेज किया जा सकता है.

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

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

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

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

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

  इस सीमा का उल्लंघन करने वाले अनुरोधों को अस्वीकार कर दिया जाता है. साथ ही, गड़बड़ी का यह मैसेज दिखता है: 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 का इस्तेमाल करना होगा.

हर UserData ऑब्जेक्ट, create या remove ऑपरेशन में मौजूद असली उपयोगकर्ता के लिए होता है. user_identifiers फ़ील्ड UserData में, ज़्यादा से ज़्यादा 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 ईमेल पते हैं, तो UserData के दो ऑब्जेक्ट भेजे जा सकते हैं. इनमें एक जैसा third_party_user_id शेयर किया जा सकता है. पहले ऑब्जेक्ट में thirdPartyUserId के साथ पहले 19 ईमेल पते शामिल करें, ताकि 20 आइडेंटिफ़ायर की सीमा में रहा जा सके. दूसरे ऑब्जेक्ट में thirdPartyUserId के साथ 20 से 30 तक के ईमेल पते शामिल करें:

{
  "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" }
  ]
}

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

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

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

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

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