Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este guia explica como a API Merchant lida com controle de versões, lançamentos e o ciclo de vida das diferentes versões.
Esquema de controle de versão
A API Merchant usa uma estratégia de controle de versão no nível da sub-API. Isso significa que cada API, por exemplo, Produtos na API Merchant, terá seu próprio ciclo de vida de versão.
Formato e apresentação do controle de versão
Versões estáveis de sub-APIs:se uma sub-API estiver em uma versão estável, todos os métodos dela também estarão. Uma versão secundária estável da API é representada como vX (por exemplo, v1, v2). Essas são as principais versões prontas para produção.
Versões Alfa de sub-APIs:se uma sub-API estiver em uma versão Alfa, todos os métodos dela também estarão. Uma versão alfa da sub-API é representada como
vXalpha (por exemplo, v1alpha, v2alpha). Eles contêm recursos experimentais de acesso antecipado destinados a testes e iteração rápida. As versões Alfa não têm garantia de estabilidade, não têm ciclo de vida definido e podem ser alteradas ou desativadas com um aviso de 30 dias.
Alterações da versão
Incrementos de versão principal (por exemplo, v1 para v2): sinalizam
mudanças incompatíveis com versões anteriores e significativas, que exigem ação do desenvolvedor.
Somente mudanças incompatíveis de sub-APIs estáveis terão um novo número de versão. Por
exemplo, v1 para v2.
Mudanças secundárias:adições ou correções compatíveis com versões anteriores são apresentadas como mudanças na versão principal atual. Essas mudanças serão detalhadas nas notas da versão principal. As adições não destrutivas a uma sub-API
serão lançadas no canal Alfa da versão estável mais recente ou
diretamente na versão estável mais recente.
Política de desativação
Desativamos periodicamente versões mais antigas das sub-APIs Merchant. Temos um período de descontinuação de 12 meses para versões principais estáveis (vX), começando com o anúncio oficial de descontinuação.
Por exemplo, se descontinuarmos a v1 da sub-API Products em 15 de janeiro de 2026, ela será desativada em 15 de janeiro de 2027 ou depois. Depois dessa data, a versão anterior da sub-API não estará mais disponível para uso.
Versão da sub-API e status do ciclo de vida
A tabela a seguir lista as versões mais recentes de cada sub-API da API Merchant:
Sub-API
Versões
Status
Contas
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Conversões
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Fontes de dados
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Inventários
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Resolução de problemas
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Parceria de feeds locais
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Notificações
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Rastreamento de pedidos
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Produtos
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Product Studio
v1alpha
Ativo
Promoções
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Cota
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Relatórios
v1 v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Avaliações
v1alpha v1beta
Ativo Será descontinuado em 28 de fevereiro de 2026
Práticas recomendadas
Verifique regularmente as notas da versão e as atualizações mais recentes para conferir novas versões, atualizações importantes, melhorias e anúncios sobre lançamentos e descontinuações de sub-APIs.
Se uma sub-API tiver duas ou mais versões estáveis, recomendamos usar sempre a mais recente.
Projete seu aplicativo para processar normalmente vários erros de sub-API,
incluindo problemas de rede, limites de taxa e os novos códigos ou mensagens de erro
que podem ser introduzidos com versões mais recentes da sub-API.
Não espere até que uma versão secundária da API esteja prestes a ser desativada para começar a planejar
o upgrade. Comece a avaliar e testar novas versões assim que elas estiverem disponíveis.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-03 UTC."],[],[],null,["This guide explains how Merchant API handles versioning, releases, and the\nlifecycle of its different versions.\n\nVersioning scheme\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\nVersioning 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\nVersion 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\n will be released to the alpha channel of the latest stable version or\n directly to the latest stable version.\n\nSunset policy\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\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| Reports | 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- 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)."]]