O V1/system/config Adobe Commerce permite transportar configurações entre sandbox e produção de maneira programática, reduzindo o trabalho manual no Admin. A automação, porém, precisa distinguir ajustes realmente portáveis de credenciais, identificadores e regras específicas de cada ambiente.
Em 8 de setembro de 2026, o Adobe Commerce as a Cloud Service disponibilizou os endpoints REST GET e PUT /V1/system/config para leitura e atualização de configurações do sistema, incluindo áreas de loja, frete, impostos, pagamentos e B2B, conforme as notas oficiais de versão do Adobe Commerce as a Cloud Service. Para operações brasileiras, isso abre espaço para implantações mais consistentes, mas também exige controles para não levar chaves de teste, regras fiscais inadequadas ou contas de homologação para a loja ativa.
O que o V1/system/config muda na operação do Adobe Commerce?
Sem um processo automatizado, alterações realizadas no sandbox precisam ser identificadas, documentadas e reproduzidas manualmente em produção. Além de consumir tempo, esse procedimento pode gerar divergências difíceis de perceber: um campo fica com valor antigo, uma opção é ativada em apenas uma store view ou um método de pagamento utiliza uma configuração diferente da validada.
A recomendação oficial é obter a configuração do sandbox por meio do GET /V1/system/config e usar o resultado no PUT /V1/system/config para sincronizar as alterações com produção. A própria Adobe delimita o recurso ao Adobe Commerce as a Cloud Service, como explica a documentação oficial em inglês. Portanto, não se deve presumir que o mesmo endpoint esteja disponível em instalações Magento Open Source, Adobe Commerce on-premises ou outros modelos de hospedagem.
O ganho mais importante não é simplesmente “copiar tudo”. É transformar a configuração em uma mudança revisável, repetível e passível de validação. O conteúdo exportado pode ser comparado, aprovado e aplicado dentro de uma janela controlada, com registro de quem executou a operação e qual resultado era esperado.
Como sincronizar configurações sem copiar riscos
1. Confirme o produto e os ambientes envolvidos
Antes de preparar qualquer chamada, confirme que origem e destino pertencem ao Adobe Commerce as a Cloud Service e que o recurso está disponível nos dois ambientes. Registre também URL, finalidade, website, store e store view que serão afetados.
Não trate um sandbox antigo como fonte confiável apenas porque ele está funcionando. Compare módulos, integrações e estrutura de lojas. Uma configuração válida em um ambiente com componentes diferentes pode provocar comportamento inesperado no destino.
2. Exporte a configuração do sandbox
Faça a leitura com uma credencial que tenha somente as permissões necessárias e armazene o resultado em local protegido. Uma chamada básica pode ser preparada desta forma, substituindo endereço e token pelos valores do ambiente:
curl --fail-with-body
--request GET
--url "${BASE_URL}/rest/V1/system/config"
--header "Authorization: Bearer ${TOKEN}"
--header "Accept: application/json"
--output system-config-sandbox.jsonEvite inserir tokens diretamente em scripts versionados, tickets ou mensagens. O arquivo de saída também deve ser tratado como sensível até que a equipe confirme quais dados ele contém. Restrinja acesso, defina prazo de retenção e não o envie automaticamente para um repositório público.
3. Compare o sandbox com a produção
Faça também uma leitura do destino e compare os arquivos fora da produção. O objetivo é separar as mudanças intencionais do ruído causado por valores exclusivos de cada ambiente.
- Igual nos dois ambientes: opções funcionais já testadas e que não dependam de contas externas diferentes.
- Exclusivo por ambiente: credenciais, URLs de retorno, identificadores de conta, remetentes de teste e integrações com endpoints de homologação.
- Exige decisão comercial: regras de impostos, países atendidos, métodos de entrega, limites, grupos de clientes e recursos B2B.
- Exige teste técnico: configurações consumidas por módulos customizados, webhooks, filas ou serviços externos.
Se a comparação revelar divergências em dependências ou extensões, resolva isso antes da sincronização. Alterar configurações não corrige incompatibilidades de pacotes. Nessa situação, vale seguir um diagnóstico de conflitos no Composer do Magento 2 separadamente.
4. Sanitize o conteúdo antes do PUT
Crie um artefato revisado em vez de encaminhar cegamente o retorno do GET. Remova ou preserve no destino tudo o que não deve atravessar ambientes. A estrutura aceita deve seguir o contrato disponibilizado pela API no ambiente utilizado; não improvise campos nem altere tipos de dados para “fazer passar”.
Para pagamentos, confira modo de teste, merchant ID, tokens, chaves, URLs e recursos como captura, estorno e carteiras digitais. Uma configuração visualmente correta não confirma que a adquirente aceitará transações reais. Se a loja utiliza Braintree, complemente a validação com estes testes de pagamento no checkout.
Em frete, preserve contratos, credenciais, tabelas, limites de peso, regiões e serviços próprios da produção. Em impostos, revise país de origem, regiões, classes, regras e arredondamento. Já nas funções B2B, observe grupos, empresas, catálogos compartilhados, permissões e políticas de compra.
5. Aplique em uma janela controlada
Depois da revisão por pares, mantenha o arquivo aprovado imutável e registre seu hash. A chamada de atualização pode seguir este formato operacional, desde que o arquivo respeite exatamente o contrato retornado e aceito pela API:
curl --fail-with-body
--request PUT
--url "${BASE_URL_PRODUCAO}/rest/V1/system/config"
--header "Authorization: Bearer ${TOKEN_PRODUCAO}"
--header "Content-Type: application/json"
--data-binary @system-config-producao-revisado.jsonCapture o código HTTP e a resposta integral sem expor segredos nos logs. Não considere a execução bem-sucedida somente porque o comando terminou sem erro visível. Faça um novo GET no destino e compare o estado efetivamente persistido com o artefato aprovado.
Checklist após o PUT /V1/system/config
A validação deve cobrir comportamento, não apenas valores no Admin. Priorize as jornadas com maior impacto operacional:
- abrir storefront e painel nas store views afetadas;
- consultar produtos, preços, impostos e disponibilidade;
- criar carrinhos como visitante e cliente autenticado;
- simular endereços de diferentes estados e faixas de CEP;
- verificar prazos, transportadoras, retirada e frete grátis;
- autorizar um pagamento controlado e acompanhar a criação do pedido;
- validar captura, cancelamento ou estorno quando aplicável;
- testar e-mails, webhooks, ERP, antifraude e integrações fiscais;
- confirmar permissões, empresas e catálogos em operações B2B;
- monitorar logs e respostas dos serviços externos.
Se nenhum método de entrega aparecer, não conclua imediatamente que o PUT danificou o módulo. Compare endereço, carrinho, website e regras com o estado anterior. O roteiro sobre frete ausente no checkout Magento 2 ajuda a separar configuração, indisponibilidade externa e falha de frontend.
Rollback e auditoria não podem ficar para depois
Antes da atualização, salve a leitura da produção em armazenamento protegido e registre a configuração esperada. O plano de reversão deve indicar quem pode executá-lo, quais dados serão restaurados e quais testes serão repetidos. Também é prudente definir um critério objetivo de interrupção, como falha generalizada no pagamento, cálculo fiscal incorreto ou desaparecimento dos métodos de entrega.
Não use o arquivo anterior como rollback automático sem revisá-lo. Algumas integrações podem alterar credenciais ou estados durante a janela, e restaurar um conteúdo desatualizado pode ampliar o incidente. Quando houver dúvida, reverta somente as alterações conhecidas e valide cada área crítica.
Perguntas frequentes sobre V1/system/config Adobe Commerce
O endpoint funciona no Magento Open Source ou Adobe Commerce on-premises?
O recurso apresentado nas notas de versão é específico do Adobe Commerce as a Cloud Service. Não presuma sua disponibilidade em Magento Open Source, Adobe Commerce on-premises ou outros modelos sem consultar a documentação da instalação.
É seguro copiar diretamente a resposta do GET para o PUT?
A Adobe descreve esse fluxo de sincronização, mas a equipe deve revisar o conteúdo antes da aplicação. Credenciais, URLs, contas de pagamento, frete, impostos e valores específicos do ambiente podem precisar ser preservados ou removidos.
Como evitar a substituição de credenciais de produção?
Compare origem e destino, classifique campos exclusivos por ambiente e gere um arquivo sanitizado. Use revisão por pares, credenciais de API com privilégio mínimo e nunca armazene tokens ou exportações sensíveis em repositórios públicos.
Como confirmar que a sincronização funcionou?
Execute um novo GET em produção, compare o resultado com o artefato aprovado e teste as jornadas críticas. Checkout, pagamento, impostos, frete, pedidos, integrações e recursos B2B precisam ser verificados conforme o escopo alterado.
Conclusão
O V1/system/config Adobe Commerce pode tornar a promoção de configurações entre sandbox e produção mais consistente, desde que a automação seja acompanhada por comparação, sanitização, aprovação, testes e rollback. Para lojas brasileiras, a atenção principal deve ficar nos valores que mudam por ambiente e nas áreas capazes de interromper a venda: pagamento, impostos, frete e integrações.
Se sua equipe precisa mapear as diferenças, preparar o procedimento ou validar a loja após a sincronização, busque suporte especializado em Adobe Commerce antes de executar a alteração em produção.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
