कोटा

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

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

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

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

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

  • हर ग्रुप के लिए एक तरीका: कुछ कोटा ग्रुप, एपीआई के सिर्फ़ एक तरीके पर लागू होते हैं. उदाहरण के लिए, लिस्टिंग डेटा सोर्स के तरीके 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 के कोटा पूल से इस्तेमाल किया जाता है.
  • ऐडवांस खाते: ऐडवांस खाते के तौर पर पुष्टि करने पर, कोटा ऐडवांस खाते के पूल से इस्तेमाल होता है. भले ही, किसी उप-खाते को टारगेट किया जा रहा हो.
    • उदाहरण: एक एजेंसी Retail Management Account (ऐडवांस खाता आईडी: 12345), एक उप-खाते Clothing Store B (खाता आईडी: 11111) को मैनेज करती है. एजेंसी, अपने क्रेडेंशियल का इस्तेमाल करके पुष्टि करती है और Clothing Store B (accounts/11111) को टारगेट करने के लिए, products.insert को कॉल करती है. कोटा, पैरंट एजेंसी के पूल (ऐडवांस खाता आईडी: 12345) से इस्तेमाल होता है, न कि उप-खाते के पूल से.
  • उप-खाते: जब एपीआई कॉल की पुष्टि, उप-खाते के क्रेडेंशियल का इस्तेमाल करके की जाती है, तो कोटा का शुल्क उस उप-खाते के अलग पूल से लिया जाता है. यह स्टैंडअलोन खाते की तरह ही काम करता है. भले ही, इसे पैरंट ऐडवांस खाता मैनेज करता हो.
    • उदाहरण: पिछले सेटअप का इस्तेमाल करके, अगर Clothing Store B (खाता आईडी: 11111), अपने खाते (accounts/11111) को टारगेट करने के लिए, products.insert को कॉल करने के लिए, अपने उप-खाते के लिए सेट अप किए गए क्रेडेंशियल का इस्तेमाल करके पुष्टि करता है, तो कोटा Clothing Store B के अलग कोटा पूल से इस्तेमाल होता है. इससे पैरंट एजेंसी का पूल इस्तेमाल नहीं होता.

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

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

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

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

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

    उदाहरण:

    • Europe Shopping Group (खाता आईडी: 10001) नाम का एक सीएसएस ग्रुप, अपने जुड़े सीएसएस डोमेन की सूची बनाना चाहता है. इस एपीआई कॉल को करने के लिए, अपने क्रेडेंशियल का इस्तेमाल करके पुष्टि करने पर, कोटा सीधे Europe Shopping Group के कोटा पूल से इस्तेमाल होता है.
    • एक सीएसएस डोमेन 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