वर्शन
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
इस गाइड में बताया गया है कि Merchant API, वर्शनिंग, रिलीज़, और अलग-अलग वर्शन के लाइफ़साइकल को कैसे मैनेज करता है.
वर्शनिंग स्कीम
Merchant API, सब-एपीआई लेवल पर वर्शनिंग की रणनीति का इस्तेमाल करता है. इसका मतलब है कि हर एपीआई, जैसे कि Merchant API में मौजूद प्रॉडक्ट का अपना वर्शन लाइफ़साइकल होगा.
सब-एपीआई के स्टेबल वर्शन: अगर कोई सब-एपीआई स्टेबल वर्शन में है, तो उसके सभी तरीके स्टेबल वर्शन में होंगे. किसी स्टेबल सब-एपीआई वर्शन को vX के तौर पर दिखाया जाता है. उदाहरण के लिए, v1, v2. ये प्रोडक्शन के लिए तैयार मुख्य वर्शन हैं.
एपीआई के ऐल्फ़ा वर्शन: अगर कोई सब-एपीआई ऐल्फ़ा वर्शन में है, तो उसके सभी तरीके ऐल्फ़ा वर्शन में होंगे. ऐल्फ़ा सब-एपीआई वर्शन को vXalpha के तौर पर दिखाया जाता है. उदाहरण के लिए, v1alpha, v2alpha. इनमें एक्सपेरिमेंट के तौर पर उपलब्ध ऐसी सुविधाएं होती हैं जिन्हें रिलीज़ होने से पहले ऐक्सेस देकर टेस्ट किया जा सकता है. साथ ही, इन्हें तेज़ी से दोहराया जा सकता है. अल्फ़ा वर्शन के लिए, स्थिरता की कोई गारंटी नहीं होती. साथ ही, इनकी कोई तय समयसीमा नहीं होती. इन्हें 30 दिनों के नोटिस के साथ बदला या बंद किया जा सकता है.
वर्शन के परिवर्तन
मेजर वर्शन में बढ़ोतरी (उदाहरण के लिए, v1 से v2): ये ऐसे बदलावों के बारे में बताते हैं जो पुराने सिस्टम के साथ काम नहीं करते हैं और जिनके लिए डेवलपर को कार्रवाई करनी होती है.
सिर्फ़ स्टेबल सब-एपीआई में हुए बड़े बदलावों के लिए, नया वर्शन नंबर होगा. उदाहरण के लिए, v1 से v2.
मामूली बदलाव: पुराने सिस्टम के साथ काम करने वाली सुविधाओं को जोड़ने या ठीक करने के लिए, मौजूदा मेजर वर्शन में बदलाव किए जाते हैं. इस तरह के बदलावों के बारे में, उस मुख्य वर्शन के रिलीज़ नोट में जानकारी दी जाएगी. सब-एपीआई में किए गए ऐसे बदलाव जो मौजूदा एपीआई को नहीं तोड़ते हैं उन्हें नए स्टेबल वर्शन के ऐल्फ़ा चैनल में या सीधे तौर पर नए स्टेबल वर्शन में रिलीज़ किया जाएगा.
सेवा बंद करने से जुड़ी नीति
हम समय-समय पर, Merchant sub-API के पुराने वर्शन बंद करते रहते हैं. हम स्टेबल मेजर वर्शन (vX) के लिए, 12 महीने की अवधि में बंद करने की सुविधा उपलब्ध कराते हैं. यह अवधि, आधिकारिक तौर पर बंद करने के एलान से शुरू होती है.
उदाहरण के लिए, अगर हम प्रॉडक्ट सब-एपीआई के v1 वर्शन को 15 जनवरी, 2026 को बंद कर देते हैं, तो यह 15 जनवरी, 2027 से पहले बंद नहीं होगा. इस तारीख के बाद, सब-एपीआई का पुराना वर्शन इस्तेमाल नहीं किया जा सकेगा.
सब-एपीआई का वर्शन और लाइफ़साइकल स्टेटस
यहां दी गई टेबल में, Merchant API के हर सब-एपीआई के सबसे नए वर्शन की सूची दी गई है:
| सब-एपीआई |
वर्शन |
स्थिति |
| खाते |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| कन्वर्ज़न |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| डेटा सोर्स |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| इन्वेंट्री |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| समस्या हल करना |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| Local feeds partnership |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| सूचनाएं |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| ऑर्डर ट्रैकिंग | v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| प्रॉडक्ट |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| Product Studio |
v1alpha |
चालू है |
| प्रचार
|
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| अनुरोध भेजने की तय सीमा |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| रिपोर्टिंग |
v1
v1beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
| समीक्षाएं |
v1alpha
v1 beta |
चालू है
28 फ़रवरी, 2026 को बंद हो जाएगा |
सबसे सही तरीके
- नए वर्शन, बड़े अपडेट, सुधारों, और सब-एपीआई के लॉन्च और बंद होने के बारे में सूचनाओं के लिए, रिलीज़ नोट और नए अपडेट नियमित तौर पर देखें.
- अगर किसी सब-एपीआई के दो या इससे ज़्यादा स्टेबल वर्शन हैं, तो हमारा सुझाव है कि हमेशा सबसे नए वर्शन का इस्तेमाल करें.
- अपने ऐप्लिकेशन को इस तरह से डिज़ाइन करें कि वह सब-एपीआई से जुड़ी अलग-अलग गड़बड़ियों को आसानी से ठीक कर सके. जैसे, नेटवर्क से जुड़ी समस्याएं, दर की सीमाएं, और गड़बड़ी के नए कोड या मैसेज. ये गड़बड़ियां, सब-एपीआई के नए वर्शन के साथ आ सकती हैं.
- अपग्रेड करने की योजना बनाने के लिए, किसी सब-एपीआई वर्शन के बंद होने का इंतज़ार न करें. नए वर्शन उपलब्ध होते ही, उनका आकलन और टेस्टिंग शुरू करें.
- अगर आपको किसी सुविधा का अनुरोध करना है या सब-एपीआई के रोडमैप के बारे में कोई समस्या है, तो हमसे संपर्क करें. इसके लिए, अपने सवाल पूछें या सुझाव/राय दें या शिकायत करें. तकनीकी सहायता के लिए Merchant API टीम से संपर्क करने के तरीके के बारे में जानने के लिए, Merchant API से जुड़ी मदद पाना लेख पढ़ें.
जब तक कुछ अलग से न बताया जाए, तब तक इस पेज की सामग्री को Creative Commons Attribution 4.0 License के तहत और कोड के नमूनों को Apache 2.0 License के तहत लाइसेंस मिला है. ज़्यादा जानकारी के लिए, Google Developers साइट नीतियां देखें. Oracle और/या इससे जुड़ी हुई कंपनियों का, Java एक रजिस्टर किया हुआ ट्रेडमार्क है.
आखिरी बार 2025-08-22 (UTC) को अपडेट किया गया.
[null,null,["आखिरी बार 2025-08-22 (UTC) को अपडेट किया गया."],[],[],null,["# Versioning\n\nThis guide explains how Merchant API handles versioning, releases, and the\nlifecycle of its different versions.\n\nVersioning scheme\n-----------------\n\nMerchant API employs a versioning strategy at the sub-API level. This means that\neach API, for example Products within the Merchant API, will have its own\nversion lifecycle.\n\n### Versioning format and presentation\n\n- **Stable sub-API versions:** If a sub-API is in a stable version then all\n its methods are in a stable version. A stable sub-API version is represented\n as **vX** (for example, **v1** , **v2**). These are production-ready major\n versions.\n\n- **Alpha sub-API versions:** If a sub-API is in an alpha, then all its\n methods are in alpha. An alpha sub-API version is represented as\n **vXalpha** (for example, **v1alpha** , **v2alpha**). They contain\n experimental, early access features intended for testing and rapid\n iteration. Alpha versions come with no stability assurance, have no defined\n lifespan and can be changed or discontinued with a notice period of 30 days.\n\n### Version changes\n\n- **Major version increments** (for example, v1 to v2): These signal\n backward-incompatible and breaking changes, which require developer action.\n Only breaking changes of stable sub-APIs will have a new version number. For\n example, v1 to v2.\n\n- **Minor changes:** Backward compatible additions or fixes are presented as\n changes to the existing major version. Such changes will be detailed in the\n release notes for that major version. Non-breaking additions to a sub-API will\n be released to the alpha channel of the latest stable version or directly to\n the latest stable version.\n\nSunset policy\n-------------\n\nWe periodically sunset older Merchant sub-API versions. We commit to a 12-month\ndeprecation window for stable major versions (vX), starting from the official\ndeprecation announcement.\n\nFor example, if we deprecate v1 of the Products sub-API on January 15, 2026, it\nwill sunset no earlier than January 15, 2027. Beyond this date, the earlier\nversion of the sub-API will no longer be available for use.\n\nSub-API version and lifecycle status\n------------------------------------\n\nThe following table lists the latest versions of each sub-API of Merchant API:\n\n| Sub-API | Versions | Status |\n|-------------------------|----------------|-------------------------------------------|\n| Accounts | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Conversions | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Data sources | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Inventories | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Issue resolution | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Local feeds partnership | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Notifications | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Order tracking | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Products | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Product Studio | v1alpha | Active |\n| Promotions | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Quota | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Reporting | v1 v1beta | Active To be discontinued on Feb 28, 2026 |\n| Reviews | v1alpha v1beta | Active To be discontinued on Feb 28, 2026 |\n\nBest practices\n--------------\n\n- Regularly check the release notes and [latest\n updates](/merchant/api/latest-updates) for new versions, major updates, improvements, and announcements about sub-API launches and deprecations.\n- If a sub-API has two or more stable versions, we suggest using the latest version at all times.\n- Design your application to gracefully handle various sub-API errors, including network issues, rate limits, and the new error codes or messages that might be introduced with newer sub-API versions.\n- Don't wait until a sub-API version is about to be sunset to start planning your upgrade. Begin evaluating and testing new versions as soon as they are available.\n- For feature requests or concerns about a sub-API roadmap, [reach out to us\n with questions or feedback](/merchant/api/support/give-feedback). For information about how to contact the Merchant API team for technical support, see [Get help with Merchant API](/merchant/api/support/get-help)."]]
