Voltar ao blog
Adobe Commerce Cloud Service: a release de outubro abre o back office às integrações
11 de outubro de 2026Adobe Commerce

Adobe Commerce Cloud Service: a release de outubro abre o back office às integrações



No Adobe Commerce as a Cloud Service, as regras do jogo mudaram: sem módulos PHP à medida, sem acesso direto à base de dados. O que a API não sabe fazer, a sua integração também não fará. É por isso que a release de 7 de outubro de 2026 merece uma leitura atenta: de uma dúzia de novidades, quase todas alargam a superfície de integração — carrinhos, preços, B2B, e-mail. Eis o que se abre, e a restrição que o acompanha.


O carrinho abre-se aos sistemas terceiros


Três novidades visam o mesmo cenário: um sistema externo — um OMS, um call center, uma ferramenta de venda assistida — que precisa de criar ou alterar carrinhos sem perturbar o cliente.


  • O preço à medida. O atributo de extensão custom_price permite definir um preço arbitrário numa linha de carrinho através dos endpoints REST padrão, reservado aos tokens de admin e de integração. Orçamentos negociados, tarifas de call center, gestos comerciais: até agora, era preciso contornar as regras de carrinho para simular tudo isto.
  • Os carrinhos isolados. Uma opção, desativada por omissão, separa os carrinhos criados pelo admin ou pelas integrações do carrinho de storefront ativo do cliente. Acabou o carrinho de orçamento que apaga aquele que o cliente estava a encher no mesmo momento.
  • O desconto de envio livre. Um endpoint de admin aplica um desconto de envio arbitrário a um carrinho, para os casos que as regras padrão não cobrem — portes oferecidos após um incidente, condição negociada em contrato.

Os preços de catálogo saem do ecrã de admin


As regras de preço de catálogo gerem-se agora em REST: criação, alteração, eliminação, pesquisa e descoberta de metadados. Um motor de pricing ou um PIM pode finalmente sincronizar as regras em vez de exigir introdução manual. E essas regras agendam-se agora à hora exata, já não apenas ao dia: uma venda flash das 9h às 13h deixa de exigir um script caseiro.


No B2B, o webhook sabe com quem fala


O webhook das tarifas de envio recebe agora o company_id do carrinho e os atributos personalizados da empresa: uma integração App Builder pode decidir a elegibilidade de uma tarifa negociada sem voltar a chamar o Commerce. Chegam dois bloqueios ao mesmo tempo: uma opção impede o registo de empresas por visitantes não autenticados (mutation createCompany), e o reCAPTCHA pode proteger os uploads de ficheiros pré-assinados. Do lado das devoluções, a API REST aceita atributos personalizados nas linhas de devolução — a sincronização dos RMA com um ERP dispensa o desvio pelo GraphQL do storefront.


Os e-mails transacionais deixam o monólito


Novos eventos permitem enviar os e-mails transacionais a partir de uma plataforma terceira — Salesforce Marketing Cloud, por exemplo — através do App Builder. Para os comerciantes que já gerem as campanhas de marketing num ESP, é a oportunidade de consolidar: os mesmos modelos, a mesma entregabilidade, o mesmo reporting para a confirmação de encomenda e para a newsletter.


A restrição que acompanha a abertura


Uma linha da release não acrescenta nada e pode partir o existente: a Bulk API impõe agora um máximo de entidades por pedido, não configurável, com erro acima do limite. Se as suas importações enviam lotes massivos, verifique-as antes da próxima sincronização completa — dividir em blocos passa a ser a norma, não uma otimização.


Por onde começar


  • Retome o backlog de integração congelado « à espera da API » e cruze-o com esta release: regras de preço de catálogo, preços custom e descontos de envio talvez já lá estejam.
  • Verifique a utilização da Bulk API: dimensão dos lotes, tratamento do erro de ultrapassagem.
  • No B2B, ative a restrição de registo de empresas e estude o webhook enriquecido se as suas tarifas de envio dependem do contrato do cliente.
  • Se uma renovação do e-mail está em espera, a via dos eventos para um ESP terceiro torna-se a opção por omissão no cloud service.

Numa plataforma SaaS, o roadmap do fornecedor é também o seu: o que a API não oferece hoje não está « por desenvolver », está « por esperar ». A release de outubro mostra que a espera pode ser curta — e que uma lista de lacunas sem data, também aqui, é uma lista errada.