कोटा

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

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

सामान्य सिद्धांत

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

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

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

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

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

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

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

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

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

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

दर के हिसाब से कोटा

हर कोटा ग्रुप के लिए, दो तरह की सीमाएं (और हर दिन के इस्तेमाल की जानकारी) तय होती हैं:

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

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

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

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

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

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

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

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

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

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

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

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

    उदाहरण:

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

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

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

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

कोटा का अपने-आप अडजस्ट होना

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