कोटा

इस दस्तावेज़ में, Merchant API पर लागू होने वाले कोटे की सूची दी गई है.

Merchant API, सभी उपयोगकर्ताओं के लिए एक स्थिर और निष्पक्ष माहौल उपलब्ध कराने के लिए, कोटा का इस्तेमाल करता है. कोटा की वजह से, एपीआई का कोई भी उपयोगकर्ता सिस्टम पर बहुत ज़्यादा लोड नहीं डाल पाता. इससे सिस्टम की परफ़ॉर्मेंस बेहतर बनी रहती है. Google पर अपने प्रॉडक्ट डेटा को मैनेज करने और कारोबार को बढ़ाने के लिए, इन कोटा के बारे में समझना ज़रूरी है.

सामान्य कॉन्सेप्ट

Merchant API के कोटा, कोटा ग्रुप के ज़रिए मैनेज किए जाते हैं.

एपीआई के तरीकों को कोटा ग्रुप के साथ मैप किया जाता है. इस मैपिंग का स्ट्रक्चर अलग-अलग हो सकता है:

  • हर ग्रुप के लिए एक तरीका: कुछ कोटा ग्रुप, एपीआई के एक तरीके पर लागू होते हैं. उदाहरण के लिए, listingDataSources.list accounts.dataSources.list मेथड का अपना कोटा ग्रुप होता है.
  • हर ग्रुप के लिए एक से ज़्यादा तरीके (बंडलिंग): अक्सर, मिलते-जुलते तरीकों को एक ही कोटा ग्रुप में बंडल कर दिया जाता है. उस ग्रुप में शामिल सभी तरीकों के लिए, रोज़ाना और हर मिनट के हिसाब से तय की गई सीमाएं एक जैसी होती हैं. सामान्य उदाहरणों में ये शामिल हैं:
    • पढ़ने से जुड़ी सभी कार्रवाइयों को एक साथ ग्रुप किया जाता है. जैसे, merchant-accounts-read-methods.
    • मिलते-जुलते तरीकों और संसाधनों के लिए, बदलाव करने की सभी कार्रवाइयों को ग्रुप करना. जैसे, merchant-accounts-write-methods.

हर तरीके के कॉल की गिनती एक बार की जाती है, भले ही वह किसी भी तरह का हो. 250 आइटम के list अनुरोध को सिर्फ़ एक बार गिना जाता है. इसे 250 get अनुरोधों के तौर पर नहीं गिना जाता.

बिल्ट-इन एचटीटीपी बैचिंग से कोटा पर कोई असर नहीं पड़ता. अनुरोधों के बैच में मौजूद हर अनुरोध को, कोटे के हिसाब से एक अनुरोध के तौर पर गिना जाता है. उदाहरण के लिए, 500 insert अनुरोधों वाले बैच अनुरोध के लिए, 500 अलग-अलग insert तरीके के अनुरोधों के तौर पर शुल्क लिया जाता है.

किसी खास क्षेत्र के लिए बैचिंग से जुड़ी ज़रूरी जानकारी: किसी खास क्षेत्र के लिए बैचिंग के तरीके (batchCreate, batchUpdate, batchDelete) को merchant_regions कोटा ग्रुप के ख़िलाफ़ एक एपीआई कॉल के तौर पर गिना जाता है. भले ही, पेलोड में क्षेत्र से जुड़ी कार्रवाइयों की संख्या कुछ भी हो.

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

नीति अपडेट करें

Merchant API, अपडेट के मामले में इन नीतियों को लागू करता है:

  • डिफ़ॉल्ट रूप से, प्रॉडक्ट की जानकारी को दिन में दो बार अपडेट किया जा सकता है. आपको पूरे दिन में कॉल को इस तरह से बांटना चाहिए कि हर मिनट के लिए तय सीमा का पालन किया जा सके.
  • डिफ़ॉल्ट रूप से, हर दिन सिर्फ़ दो बार अपने उप-खातों को अपडेट किया जा सकता है. उप-खाते को हर दिन अपडेट करने का कोटा, कुल उप-खातों के हिसाब से तय किया जाता है.
  • डिफ़ॉल्ट रूप से, हर दिन हर उप-खाते के लिए, डेटा सोर्स के तरीकों को सिर्फ़ दो बार कॉल किया जा सकता है. जैसे, list या create.

रेट कोटा

हर कोटा ग्रुप के लिए, दो तरह की सीमाएं होती हैं. साथ ही, रोज़ाना इस्तेमाल करने की सीमा भी होती है:

  • रोज़ाना की सीमा (quotaLimit): हर दिन ज़्यादा से ज़्यादा इतने अनुरोध किए जा सकते हैं. हर दिन के कोटे की सीमाएं, दोपहर 12:00 बजे यूटीसी पर रीसेट होती हैं.
  • हर मिनट के हिसाब से तय सीमा (quotaMinuteLimit): हर मिनट में किए जा सकने वाले अनुरोधों की ज़्यादा से ज़्यादा संख्या. इससे अनुरोधों की दर को कंट्रोल किया जाता है. हर मिनट के कोटे की सीमाएं, बार-बार रीसेट होने वाली तय समयसीमा का इस्तेमाल करती हैं. इस समयसीमा की शुरुआत, उस तरीके और संसाधन के लिए पहला एपीआई कॉल किए जाने के समय से होती है. उदाहरण के लिए, अगर आपने सुबह 10:01:30 बजे कॉल किया है, तो उस तरीके के लिए हर मिनट का कोटा, सुबह 10:02:30 बजे तक चलेगा.
  • रोज़ाना इस्तेमाल (quotaUsage): यह उन अनुरोधों की संख्या है जो मौजूदा दिन के लिए, रोज़ाना इस्तेमाल की सीमा के हिसाब से पहले ही किए जा चुके हैं और गिने जा चुके हैं. अगर यह फ़ील्ड मौजूद नहीं है, तो इसका मतलब है कि इस ग्रुप के लिए अब तक कोई कोटा इस्तेमाल नहीं किया गया है.

आपको quotas.list तरीके के जवाब में, पहले बताए गए तीन फ़ील्ड (quotaLimit, quotaMinuteLimit, और quotaUsage) दिख सकते हैं.

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

कोटा का बंटवारा और हैरारकी

इस सेक्शन में बताया गया है कि Merchant API, कोटे के इस्तेमाल को किसके लिए ट्रैक करता है और लागू करता है:

आम तौर पर, एपीआई अनुरोध करने वाले उपयोगकर्ता के हिसाब से कोटा का शुल्क लिया जाता है.

  • स्टैंड-अलोन खाते: एपीआई कॉल की पुष्टि करने वाले स्टैंड-अलोन खातों के लिए, वह अनुरोध उस खाते के कोटे में गिना जाता है.
    • उदाहरण: कारोबारी या कंपनी Shoe Store A (खाता आईडी: 12345) अपने सेवा खाते का इस्तेमाल करके पुष्टि करती है, ताकि वह अपने खाते (accounts/12345) को टारगेट करने के लिए products.insert को कॉल कर सके. कोटे का इस्तेमाल, Shoe Store A के कोटे के पूल से किया जाता है.
  • ऐडवांस खाते: ऐडवांस खाते के तौर पर पुष्टि करने पर, ऐडवांस खाते के पूल से कोटा इस्तेमाल होता है. भले ही, उप-खाते को टारगेट किया जा रहा हो.
    • उदाहरण: कोई एजेंसी, रीटेल मैनेजमेंट खाता (ऐडवांस खाता आईडी: 12345) कपड़ों की दुकान B (खाता आईडी: 11111) नाम के उप-खाते को मैनेज करती है. एजेंसी अपने क्रेडेंशियल का इस्तेमाल करके पुष्टि करती है और products.insert को कॉल करती है. इससे कपड़ों की दुकान B (accounts/11111) को टारगेट किया जाता है. कोटा, पैरंट एजेंसी के पूल (ऐडवांस खाता आईडी: 12345) से इस्तेमाल किया जाता है, न कि उप-खाते के पूल से.
  • उप-खाते: जब एपीआई कॉल की पुष्टि, उप-खाते के क्रेडेंशियल का इस्तेमाल करके की जाती है, तो कोटा उस उप-खाते के अलग पूल से लिया जाता है. यह एक स्टैंड-अलोन खाते की तरह ही काम करता है. भले ही, इसे माता-पिता के ऐडवांस खाते से मैनेज किया जाता हो.
    • उदाहरण: पिछले उदाहरण में बताए गए सेटअप का इस्तेमाल करके, अगर कपड़ों की दुकान B (खाता आईडी: 11111) अपने उप-खाते के लिए सेट अप किए गए क्रेडेंशियल का इस्तेमाल करके पुष्टि करती है, ताकि वह अपने खाते (accounts/11111) को टारगेट करने के लिए products.insert को कॉल कर सके, तो कोटा कपड़ों की दुकान B के अलग-अलग कोटा पूल से इस्तेमाल किया जाएगा. इससे पैरंट एजेंसी के पूल पर कोई असर नहीं पड़ेगा.

सामान्य नियमों के अपवाद

कोटा असाइन करने के सामान्य नियमों के कुछ अपवाद हैं:

  • Accounts.list: इस तरीके के लिए कोटा, पुष्टि किए गए उस उपयोगकर्ता या सेवा खाते से लिया जाता है जो कॉल कर रहा है. यह कोटा, Merchant Center खाते के आईडी से नहीं लिया जाता. इसके कोटे के इस्तेमाल की जानकारी, Merchant Center API के स्टैंडर्ड डाइग्नोस्टिक्स पेज पर नहीं दिखेगी. अगर आपके पास ऐडवांस खाता है, तो हमारा सुझाव है कि आप accounts.listSubaccounts तरीके का इस्तेमाल करें. इससे आपके ऐडवांस खातों के कोटे में गिनती होती है.
  • समस्या हल करने के तरीके: ये तरीके हमेशा उस खाते के कोटे में गिने जाते हैं जिसकी समस्याओं के लिए अनुरोध किया जा रहा है. भले ही, कोई दूसरा खाता अनुरोध की पुष्टि कर रहा हो.

बजट के बंटवारे की हैरारकी

  • कंपैरिज़न शॉपिंग सर्विस (सीएसएस): सीएसएस ऐसी वेबसाइटें होती हैं जो प्रॉडक्ट के ऑफ़र इकट्ठा करती हैं. साथ ही, खरीदारों को खरीदारी करने के लिए खुदरा दुकानदारों की वेबसाइटों पर रीडायरेक्ट करती हैं. एपीआई कॉल करते समय, कोटा उस सीएसएस ग्रुप, सीएसएस डोमेन, खाते या उप-खाते पर लागू होते हैं जिसके लिए आपने पुष्टि की है.

    उदाहरण:

    • Europe Shopping Group नाम का सीएसएस ग्रुप (खाता आईडी: 10001) अपने सीएसएस ग्रुप से जुड़े सीएसएस डोमेन की सूची दिखाना चाहता है. इस एपीआई कॉल को करने के लिए, अपने क्रेडेंशियल से पुष्टि करके, कोटा सीधे Europe Shopping Group के कोटा पूल से इस्तेमाल किया जाता है.
    • सीएसएस डोमेन TopDeals CSS (खाता आईडी: 20002) पुष्टि करता है कि वह अपने किसी कारोबारी या कंपनी के खाते (accounts/30003) को टारगेट करने वाले किसी तरीके को कॉल कर सकता है, ताकि उसे लेबल असाइन किया जा सके. यह कोटा, कारोबारी या कंपनी के खाते के कोटा पूल से नहीं, बल्कि TopDeals CSS के कोटा पूल से इस्तेमाल किया जाता है.

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

नीचे दिए गए डायग्राम में, सीएसएस ग्रुप, सीएसएस, मार्केटप्लेस, ऐडवांस खातों, स्टैंडअलोन खातों, और उप-खातों की हैरारकी दिखाई गई है.

सीएसएस ग्रुप, पुष्टि करने का सबसे ऊपर का लेवल होता है. इसमें अलग-अलग सीएसएस, उनके खाते, और सबसे नीचे के लेवल पर उप-खाते होते हैं.

कोटा अपने-आप अडजस्ट होने की सुविधा

Merchant API में, कुछ सेवाओं के लिए कोटा मैनेज करने का सिस्टम अपने-आप काम करता है. यह सिस्टम, कारोबारियों या कंपनियों के इस्तेमाल, ऑफ़र, और खाते के साइज़ के आधार पर, उनके लिए कोटा की सीमाएं तय करता है. Merchant API, इन कोटों का हिसाब हर दिन लगाता है.

अपने-आप कोटा अडजस्ट होने की सुविधा में शामिल कोटा ग्रुप ये हैं:

प्रॉडक्ट सेवाएं

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

खातों से जुड़ी सेवाएं

  • Merchant API में, खाते से जुड़े अलग-अलग विस्तृत संसाधनों के लिए, तरीकों के सभी कोटा ग्रुप.
  • रोज़ाना कॉल करने का कोटा, उस खाते के लिए अनुमति वाले ज़्यादा से ज़्यादा उप-खातों की संख्या पर सेट होता है. इससे हर दिन, हर उप-खाते के लिए दो बार तक कॉल पढ़ने की अनुमति मिलती है.

डेटा सोर्स की सेवाएं

  • Merchant API में डेटा सोर्स से जुड़े संसाधनों के लिए, सभी कोटा ग्रुप. जैसे, list या create. इनका इस्तेमाल ऐडवांस खाता, अपने उप-खातों पर करता है.
  • आम तौर पर, हर दिन कॉल करने का कोटा, ऐडवांस खाते से जुड़े उप-खातों की संख्या का दोगुना होता है. इससे यह माना जाता है कि कारोबारी या कंपनी, हर दिन अपने हर उप-खाते के डेटा सोर्स को दो बार अपडेट कर सकती है.

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

कोटा से ज़्यादा स्टोरेज का इस्तेमाल करने पर क्या होता है

कोटा खत्म होने के बाद, एपीआई रिस्पॉन्स में गड़बड़ियां दिखेंगी. साथ ही, ये गड़बड़ियां आपके Merchant Center खाते में मौजूद डाइग्नोस्टिक्स पेज पर भी दिखेंगी:

  • प्रति मिनट: quota/request_rate_too_high
{
    "error": {
        "code": 429,
        "message": "Quota per minute exceeded. Please distribute your requests over a longer time period. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
        "status": "RESOURCE_EXHAUSTED",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.ErrorInfo",
                "reason": "quotaExceeded",
                "domain": "merchantapi.googleapis.com",
                "metadata": {
                    "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
                    "REASON": "QUOTA_REQUEST_RATE_TOO_HIGH"
                }
            }
        ]
    }
}
  • हर दिन: quota/daily_limit_exceeded
{
    "error": {
        "code": 429,
        "message": "Daily request quota exceeded. Please reduce number of requests. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
        "status": "RESOURCE_EXHAUSTED",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.ErrorInfo",
                "reason": "quotaExceeded",
                "domain": "merchantapi.googleapis.com",
                "metadata": {
                    "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
                    "REASON": "QUOTA_TOO_MANY_REQUESTS"
                }
            }
        ]
    }
}

यहां दी गई गड़बड़ियां, Merchant Center की सीमाओं से जुड़ी हैं. इनका Merchant API के कोटे से कोई संबंध नहीं है. आपके पास सामान, फ़ीड या उप-खातों का कोटा बढ़ाने का अनुरोध करने का विकल्प है:

  • too_many_items: कारोबारी या कंपनी का कोटा पूरा हो गया है
  • too_many_subaccounts: इससे ज़्यादा उप-खाते नहीं बनाए जा सकते

मॉनिटरिंग और विज़िबिलिटी

किसी खाते के लिए कॉल के मौजूदा कोटे और इस्तेमाल की जानकारी देखने के लिए, खाते के नाम के साथ quotas.list को कॉल करें.

POST https://merchantapi.googleapis.com/quota/v1/accounts/{ACCOUNT_ID}/quotas
Content-Type: application/json
Authorization: Bearer {ACCESS_TOKEN}

इनकी जगह ये डालें:

  • ACCOUNT_ID: आपके Merchant Center का आईडी
  • ACCESS_TOKEN: एपीआई कॉल करने के लिए अनुमति देने वाला टोकन

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

{
    "quotaGroups": [
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-quota-listquotagroups",
            "quotaUsage": "2",
            "quotaLimit": "1000",
            "methodDetails": [
                {
                    "method": "quotaservice.listquotagroups",
                    "version": "v1",
                    "subapi": "quota",
                    "path": "quota/v1/quotaservice.listquotagroups"
                }
            ],
            "quotaMinuteLimit": "10"
        },
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-commission-group-list",
            "quotaLimit": "10000",
            "methodDetails": [
                {
                    "method": "commissiongroupservice.listcommissiongroups",
                    "version": "v1",
                    "subapi": "youtube",
                    "path": "youtube/v1/commissiongroupservice.listcommissiongroups"
                }
            ],
            "quotaMinuteLimit": "60"
        },
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-merchantreviews-list",
            "quotaLimit": "20000000",
            "methodDetails": [
                {
                    "method": "merchantreviewsservice.listmerchantreviews",
                    "version": "v1",
                    "subapi": "reviews",
                    "path": "reviews/v1/merchantreviewsservice.listmerchantreviews"
                }
            ],
            "quotaMinuteLimit": "60000"
        }
    ]
}

कोटा बढ़ाने की प्रोसेस

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

  • ऑटोमैटिक कोटा वाले संसाधनों (ऐडवांस खातों के लिए products, accounts, और datasources) के लिए: खास स्थितियों में, सिर्फ़ कुछ समय के लिए कोटा बढ़ाने का अनुरोध किया जा सकता है. जैसे, किसी नई मार्केट में लॉन्च करना या शॉपिंग के सीज़न में ज़्यादा ट्रैफ़िक मिलना. हम इन संसाधनों के लिए, स्थायी तौर पर कोटा बढ़ाने का अनुरोध स्वीकार नहीं करते.
  • अपने-आप तय होने वाले कोटे के बिना अन्य सभी संसाधनों के लिए: ज़रूरत के हिसाब से कोटे में बढ़ोतरी का अनुरोध करें.

हमारा सुझाव है कि आप समय-समय पर अपने कोटे की जांच करें, ताकि यह पक्का किया जा सके कि आपके पास लागू करने के लिए ज़रूरी कोटा है. साथ ही, यह भी देखें कि आपका कोटा अपने-आप कैसे अडजस्ट होता है. हर एपीआई मेथड ग्रुप के लिए, हर दिन के कोटे की मौजूदा सीमा, हर मिनट की सीमा, और हर दिन के मौजूदा इस्तेमाल की जानकारी देखने के लिए, quotas.list तरीके का इस्तेमाल करें.

सबसे सही तरीके

इन सबसे सही तरीकों को लागू करने से, यह पक्का करने में मदद मिलती है कि आपका इंटिग्रेशन ठीक से काम कर रहा है. साथ ही, इससे कोटे से जुड़ी अनचाही गड़बड़ियों से बचा जा सकता है और Merchant Center के संसाधनों का बेहतर तरीके से इस्तेमाल किया जा सकता है.

अनुरोधों के डिस्ट्रिब्यूशन को ऑप्टिमाइज़ करना

  • अनुरोधों को बराबर हिस्सों में बांटें: एक साथ कई अनुरोध न भेजें. एपीआई कॉल को पूरे दिन में बराबर बांटें, ताकि एक मिनट में किए जा सकने वाले कुल अनुरोधों की सीमा (quotaMinuteLimit) के अंदर रहा जा सके.
  • ऐक्टिव थ्रॉटलिंग: अपने ऐप्लिकेशन में क्लाइंट-साइड अनुरोध संख्या सीमित करना (थ्रॉटलिंग) लागू करें. ज़्यादा ट्रैफ़िक को अस्वीकार करने के लिए, सिर्फ़ Google के सर्वर पर भरोसा न करें. सोर्स पर अनुरोध दर को कंट्रोल करें.

गड़बड़ी को आसानी से ठीक करना

  • एचटीटीपी 429 को मैनेज करें: आपका ऐप्लिकेशन, 429 Too Many Requests गड़बड़ियों (quota/request_rate_too_high) को मैनेज करने के लिए तैयार होना चाहिए.
  • जिटर के साथ एक्सपोनेंशियल बैकऑफ़: अनुरोध पूरे न होने पर, उन्हें फिर से भेजने की कोशिश करें. खास तौर पर, 429 स्टेटस कोड मिलने के बाद. इसके लिए, एक्सपोनेंशियल बैकऑफ़ (इंतज़ार का समय बढ़ाना) का इस्तेमाल करें. साथ ही, "जिटर" (अनियमित देरी) जोड़ें. जिटर की वजह से, "रीट्राई स्टॉर्म" की समस्या नहीं होती. इसमें कई क्लाइंट इंस्टेंस एक ही समय पर फिर से कोशिश करते हैं. इससे सर्वर पर फिर से ज़्यादा लोड पड़ता है.
  • फिर से कोशिश करने के बारे में दिए गए सुझावों का पालन करें: अगर एपीआई से मिले जवाब में फिर से कोशिश करने के बारे में जानकारी या हेडर शामिल हैं, तो उनका इस्तेमाल यह तय करने के लिए करें कि कॉल कब फिर से शुरू किए जाएं.

बेकार के कॉल कम करना

  • पुराने कॉल (404 NOT_FOUND) को रोकना: ऐसे संसाधनों का अनुरोध करने या उन्हें मिटाने से बचें जो अब मौजूद नहीं हैं. पूरे न हो पाने वाले कॉल भी एपीआई के कोटे का इस्तेमाल करते हैं. Merchant Center के एपीआई डाइग्नोस्टिक्स में मौजूद गड़बड़ियों को मॉनिटरNOT_FOUND करें, ताकि पुरानी स्थिति को ट्रैक करने या ज़रूरत से ज़्यादा पोलिंग का पता लगाया जा सके.
  • अपडेट करने से पहले पुष्टि करें: अपडेट करने का अनुरोध भेजने से पहले, यह देख लें कि डेटा में बदलाव हुआ है या नहीं. ऐसे अपडेट न भेजें जिनमें एक जैसी वैल्यू लिखी गई हों.
  • कैशिंग का इस्तेमाल करें: जब सही हो, तब जवाबों को स्थानीय तौर पर कैश मेमोरी में सेव करें.जैसे, प्रॉडक्ट की जानकारी, सेटिंग. इससे, बिना बदले डेटा के लिए बार-बार get या list कॉल करने से बचा जा सकता है.
  • ऐडवांस खाते और उप-खाते: अगर आपके पास ऐडवांस खाता है, तो ऐडवांस खाते के लेवल पर पुष्टि करें. ऐसा तब करें, जब आपको कॉल को ऐडवांस खातों के शेयर किए गए पूल में शामिल करना हो.
  • listSubaccounts का इस्तेमाल करें: ऐडवांस खातों के लिए, accounts.list के बजाय accounts.listSubaccounts का इस्तेमाल करें. accounts.list का कोटा, कॉल करने वाले उपयोगकर्ता से लिया जाता है, न कि एमसी आईडी से. साथ ही, यह स्टैंडर्ड डाइग्नोस्टिक्स में नहीं दिखता. listSubaccounts को आपके एमसीए के कोटे में शामिल किया जाता है.
पीछे जाएं
Overview
आगे बढ़ें
Merchant Center limits