O V1/system/config Adobe Commerce permite automatizar a leitura e a atualização de configurações entre ambientes, mas não transforma todo ajuste de sandbox em um valor seguro para produção. Credenciais de gateways, contas de transportadoras, regras fiscais, escopos de loja e parâmetros B2B precisam ser filtrados antes de qualquer sincronização.
Os endpoints REST GET e PUT /V1/system/config foram disponibilizados em produção em 8 de setembro de 2026 no Adobe Commerce as a Cloud Service. Segundo as notas oficiais de versão, o recurso permite ler e atualizar programaticamente configurações relacionadas à loja, frete, impostos, pagamentos e B2B.
O que o V1/system/config Adobe Commerce muda no deploy?
Sem automação, uma configuração aprovada no sandbox precisa ser documentada e reproduzida manualmente em produção. Esse processo pode gerar divergências: um campo fica esquecido, um escopo é selecionado incorretamente ou uma alteração é feita diretamente na loja ativa sem registro adequado.
Com GET e PUT, a equipe pode comparar estados, versionar uma representação sanitizada das configurações e aplicar somente mudanças aprovadas. A documentação internacional também descreve a sincronização programática entre sandbox e produção, conforme as release notes do Adobe Commerce as a Cloud Service.
O recurso é específico do Adobe Commerce as a Cloud Service. Portanto, a existência desses endpoints não deve ser presumida em instalações Magento Open Source ou em outras modalidades de hospedagem sem a confirmação da documentação correspondente.
9 controles antes de usar GET e PUT /V1/system/config
1. Faça primeiro um inventário somente para leitura
Comece pelo GET e registre quais grupos de configuração são retornados em cada ambiente. O objetivo inicial não é alterar produção, mas descobrir diferenças, responsáveis e dependências.
Classifique cada item como portável, específico do ambiente, secreto ou pendente de análise. Guarde os arquivos de trabalho em local restrito, pois uma exportação pode conter dados que não devem entrar em repositórios, tickets públicos ou mensagens internas sem proteção.
2. Trabalhe com uma lista permitida, não com uma cópia integral
Uma allowlist reduz o risco de transportar campos desconhecidos. Em vez de enviar toda a resposta do sandbox para produção, selecione apenas caminhos revisados e necessários ao deploy.
Uma matriz simples pode conter caminho, escopo, valor esperado, proprietário, risco e procedimento de reversão. Novos campos devem ficar bloqueados até serem avaliados. Isso evita que uma mudança na plataforma ou em uma extensão amplie silenciosamente o conteúdo sincronizado.
3. Retire credenciais e identificadores exclusivos do ambiente
Chaves de API, senhas, tokens, webhooks, IDs de conta e credenciais de pagamento não devem ser copiados automaticamente do sandbox. O mesmo cuidado vale para contas de transportadoras, serviços antifraude, ERPs e integrações fiscais.
Esses valores devem vir de um cofre de segredos ou de um processo controlado de configuração do ambiente. Nunca registre o conteúdo integral da resposta em logs de CI/CD. Se o pipeline precisar informar diferenças, prefira exibir o caminho alterado e uma versão mascarada do valor.
4. Confirme website, store e store view
Uma configuração correta no escopo global pode estar errada para um website específico. Antes do PUT, documente onde cada valor deve valer e verifique se há herança ou sobrescrita.
Esse cuidado é importante em operações com marcas, países, moedas ou domínios diferentes. Uma mudança aplicada no escopo errado pode habilitar um método de pagamento onde ele não deveria existir ou substituir uma configuração local válida.
5. Trate pagamentos como uma etapa separada
Configurações de pagamento merecem aprovação própria. Além das credenciais, revise modo de operação, captura, moeda, países permitidos, ordem de exibição, carteiras digitais e regras adicionadas por módulos.
Depois da alteração, execute compras controladas e acompanhe autorização, criação do pedido, captura e estorno. Se a loja utiliza Braintree, aproveite o roteiro de testes do Braintree no checkout do Adobe Commerce para organizar cenários sem limitar a validação à aparência do método.
6. Revalide frete e impostos com cenários brasileiros
Não basta verificar se o método de entrega aparece. Teste CEPs atendidos e não atendidos, diferentes pesos, valores de carrinho, produtos virtuais e endereços de regiões distintas. Contas de homologação e produção de uma transportadora podem devolver serviços, prazos ou contratos diferentes.
Para impostos, compare produtos, classes fiscais, regiões e totais antes e depois da mudança. A inclusão dessas áreas no escopo oficial dos endpoints exige cautela porque os valores podem ser específicos de cada ambiente, como mostra a descrição nas notas de versão do serviço. Se as opções de entrega desaparecerem, siga uma investigação estruturada sobre frete ausente no checkout Magento 2 antes de substituir o módulo.
7. Verifique dependências das configurações B2B
Em operações B2B, uma chave pode depender de empresas, papéis, limites, catálogos compartilhados, aprovação de pedidos ou outros recursos previamente configurados. Sincronizar o valor sem a dependência correspondente pode deixar o Admin aparentemente correto, mas produzir um fluxo incompleto para o comprador.
Inclua contas de teste com diferentes permissões e valide login, visualização do catálogo, solicitação de cotação e aprovação, conforme os recursos efetivamente utilizados pela loja.
8. Gere e aprove um diff antes do PUT
O pipeline deve criar uma comparação legível entre o estado atual e o estado desejado. A aprovação precisa mostrar caminhos, escopos e valores mascarados, sem expor segredos.
Para arquivos JSON já sanitizados, ferramentas locais podem ajudar na revisão:
jq -S . sandbox-sanitizado.json > sandbox-ordenado.json
jq -S . producao-sanitizado.json > producao-ordenado.json
diff -u producao-ordenado.json sandbox-ordenado.jsonIsso apenas organiza a comparação; não determina se uma mudança é comercialmente correta. O resultado ainda deve ser revisado pelos responsáveis por tecnologia, pagamentos, logística, fiscal ou B2B, conforme a área afetada.
9. Prepare validação e reversão
Antes de escrever em produção, registre o estado anterior das chaves autorizadas e defina como restaurá-las. Não dependa de memória, captura de tela ou de uma cópia completa não revisada.
Após o PUT, confira o retorno da operação, releia as configurações, limpe apenas os caches necessários segundo o procedimento do ambiente e execute testes funcionais. Observe logs e integrações, mas evite registrar tokens ou respostas sensíveis. Também confirme se tarefas assíncronas continuam operando; quando houver atrasos, o roteiro de diagnóstico do cron do Magento 2 ajuda a separar coincidência de consequência do deploy.
Fluxo recomendado para sandbox e produção
- Leia os dois ambientes e armazene os resultados com acesso restrito.
- Sanitize segredos e identificadores exclusivos.
- Selecione somente caminhos presentes na allowlist.
- Compare escopos e valores em um diff revisável.
- Obtenha aprovação dos responsáveis pelas áreas afetadas.
- Faça backup lógico das chaves que serão alteradas.
- Aplique um conjunto pequeno e rastreável de mudanças.
- Releia o estado de produção e valide checkout, frete, impostos e B2B.
- Reverta os valores aprovados se os critérios de aceite não forem atendidos.
O que não deve ser automatizado sem análise
- credenciais, tokens, senhas e chaves privadas;
- URLs de webhook ou callback específicas do ambiente;
- contas de pagamento, antifraude, frete, ERP e serviços fiscais;
- e-mails operacionais que possam disparar mensagens reais;
- valores cujo escopo de website ou store view não esteja documentado;
- campos adicionados por extensões sem responsável e teste definidos.
A automação deve reduzir trabalho manual sem remover revisão, segregação de funções e rastreabilidade. Quanto maior o impacto da configuração sobre pedidos ou receita, menor deve ser o lote de mudanças.
Conclusão
O V1/system/config Adobe Commerce pode tornar o deploy mais consistente, desde que seja usado como mecanismo de mudança controlada, e não como atalho para copiar o sandbox inteiro. Allowlist, mascaramento de segredos, revisão de escopos, diff aprovado, testes de negócio e reversão são os controles essenciais.
Se a sua operação precisa estruturar essa automação ou investigar divergências entre ambientes, uma revisão técnica especializada pode ajudar a mapear configurações, dependências e critérios de validação antes da primeira escrita em produção.
Perguntas frequentes
Quais configurações podem ser sincronizadas por V1/system/config?
As notas oficiais citam configurações de loja, frete, impostos, pagamentos e B2B. A equipe deve consultar o retorno disponível no próprio ambiente e criar uma lista permitida, pois nem todo valor retornado é portável entre sandbox e produção.
Como evitar o envio de credenciais de sandbox para produção?
Remova segredos da carga de sincronização, use uma allowlist de caminhos aprovados e injete credenciais por um cofre ou processo restrito ao ambiente. Logs e diffs também devem mascarar os valores.
O endpoint pode alterar pagamentos e frete?
Essas áreas estão incluídas no escopo informado nas notas de versão. Por isso, mudanças relacionadas a elas devem ter aprovação específica e testes com endereços, carrinhos, meios de pagamento e contas adequadas à produção.
Como validar a sincronização depois do PUT?
Releia as configurações, compare o resultado com o estado aprovado e execute testes funcionais. Valide no mínimo navegação, checkout, pagamento, frete, impostos e recursos B2B utilizados pela operação, mantendo um plano de reversão.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
