Quando a Integração Trava Tudo · 16 de outubro de 2026 · 7 min

Spryker ou CWS Platform: por onde passa o preço por cliente na integração com o ERP?

Comparativo de arquitetura pela lente de CTO: o que o time técnico mantém em código e por onde passa o preço por cliente na integração com o ERP.

Líder de tecnologia em pé diante de uma mesa alta, em um escritório claro com divisórias de vidro, avaliando a arquitetura da plataforma.

Nota editorial: comparativo de arquitetura entre Spryker e a CWS Platform, escrito para quem responde como CTO. Todo fato sobre Spryker vem da documentação pública dele, com o endereço ao lado.

Uma plataforma em que parte dos processos, como o ciclo do pedido, é modelada no código do projeto costuma agradar a quem lidera tecnologia num distribuidor. A conta aparece depois: esse código passa a ser do seu time, e cada integração com o ERP precisa de um caminho de API que cubra o dado que o negócio usa.

Há dois desenhos em jogo. Em um, o time do cliente mantém no projeto o código de parte dos processos. No outro, a regra comercial do distribuidor já vive na plataforma como configuração, e a integração leva e traz dados sem carregar a política de preço.

Este comparativo olha para Spryker e CWS Platform só por esse ângulo: o que o time técnico constrói, por onde a integração passa e o que a documentação diz sobre os caminhos de API. Não é um ranking de funcionalidades.

Leia mais em O Custo da Venda Assista no YouTube Inscreva-se no canal

O que o Spryker resolve bem

O Spryker traz recursos B2B prontos para montar a estrutura da empresa compradora. O Company Account organiza a empresa em unidades de negócio e usuários, com papéis e permissões que restringem ou ampliam o acesso a produtos e pedidos.

Etapas do pedido ligadas em sequência dentro de uma moldura que representa o código do projeto, mantido pelo time técnico do cliente.

O preço de contrato entra pelo Merchant Custom Prices, em que a relação comercial é uma dimensão de preço ao lado de modo, volume, loja e moeda. O ciclo do pedido é modelado em máquinas de estado configuráveis por projeto, descritas no guia de Order Management System, o que dá ao time técnico controle fino sobre cada etapa.

Para compras corporativas, o PunchOut Gateway implementa os fluxos OCI e cXML com sistemas de eProcurement. Para quem tem um time de engenharia que quer controlar o código de cada processo, esse conjunto é uma base sólida.

Onde a arquitetura diverge

A divergência que interessa ao CTO está no caminho que a integração percorre. No Spryker, as APIs se dividem por ator e por padrão de uso: Storefront API, Back Office API, Merchant API e a Data Exchange API para operações de dados em massa. O ciclo do pedido é modelado em máquinas de estado configuradas no projeto, e o preço de contrato é cadastrado no Back Office ou no Merchant Portal.

O ERP envia dados à loja por uma carga em lote, enquanto o preço por cliente segue por um caminho separado, fora dessa carga.

A documentação do próprio fornecedor registra dois pontos que entram na conta de quem desenha a integração com o ERP:

limitação registrada na documentação do fornecedor em 30/07/2026: a Data Exchange API não suporta preço específico por cliente nem operações do Order Management System ("Product Prices per Customer: Customer-specific pricing is not supported in the Data Exchange API.", "The Data Exchange API does not support Order Management System operations.", https://docs.spryker.com/docs/integrations/spryker-api/backend-api/data-exchange-api/data-exchange-api-limitations.html).
limitação registrada na documentação do fornecedor em 30/07/2026: a Glue recebe correções, segurança e compatibilidade, mas não ganha novos endpoints ("Glue gets bugfixes, security, and compatibility, no new endpoints", https://docs.spryker.com/docs/integrations/spryker-api/getting-started-with-apis/api-roadmap-and-adoption.html).

Para um distribuidor, preço por cliente e estado do pedido são justamente os dados que mais transitam entre ERP e portal. Quando a API de carga em massa não os cobre, o time técnico desenha outro caminho para eles, e esse caminho passa a fazer parte do que precisa ser mantido.

Na CWS Platform, a regra comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace): tabelas de preço, regras e contratos são configurados na plataforma e também podem chegar do ERP ou do CRM por API, com casas decimais customizáveis. A plataforma é API-first e headless, com APIs REST e webhooks para avisar os sistemas da empresa, e todos os clientes rodam a mesma versão da plataforma.

decisão	Spryker, pelo mecanismo documentado	CWS Platform
Onde ficam a regra do pedido e o preço de contrato	Ciclo do pedido em máquinas de estado configuradas no projeto; preço de contrato cadastrado no Back Office ou no Merchant Portal	Em parâmetros do Commerce Rules Engine (CDL Workspace), alterados por configuração ou recebidos por API
Por onde passa o preço por cliente na carga em massa	Fora da Data Exchange API, que não o suporta	Tabelas, regras e contratos recebidos do ERP ou do CRM por API
Como a API evolui	A Glue segue suportada sem endpoints novos, e os recursos novos chegam pela API Platform	Todos os clientes na mesma versão da plataforma

A escolha técnica é decidir se a política comercial do distribuidor vai virar código mantido pelo seu time ou parâmetro mantido por configuração na plataforma.

O que muda na operação, pela lente de CTO

O custo de manter integrado cresce com o número de caminhos de dado que o seu time escreveu e precisa acompanhar. Preço por cliente, estado do pedido, crédito e estoque por origem são os dados que mudam todo dia na distribuição, e cada um deles precisa de um caminho de ida e volta com o ERP.

O ERP envia dados por API, a regra comercial fica em parâmetros da plataforma e cliente e vendedor chegam ao mesmo pedido.

Três perguntas ajudam a levar esse ponto para qualquer avaliação: quais dados comerciais a API de carga em massa cobre e quais ficam de fora; qual parte da regra de pedido vive no código do projeto; e quem migra as integrações quando a API que o projeto usa deixa de evoluir.

Na CWS Platform, um vendedor atende milhares de clientes, e cliente e vendedor usam a mesma interface, no mesmo pedido. O pedido registra quem montou o carrinho e quem escolheu o pagamento. A integração com ERP, CRM, fiscal e pagamentos é por API, e o cálculo de impostos pode ser delegado ao motor fiscal que o cliente já usa.

Quando escolher o Spryker

O Spryker atende bem a cenários em que o controle do código é o objetivo:

Time de engenharia que quer controlar cada processo. Escolha essa arquitetura quando a empresa tem um time próprio que quer modelar o ciclo do pedido em máquinas de estado e manter esse código, como descrito no guia de Order Management System.

Compras corporativas por eProcurement. Escolha essa arquitetura quando os compradores operam por OCI ou cXML e a loja precisa responder a esses sistemas, como faz o PunchOut Gateway.

Estrutura de empresa compradora com permissões finas. Escolha essa arquitetura quando a operação precisa de unidades de negócio, usuários e papéis com permissões detalhadas, como no Company Account.

Quando a CWS Platform é a escolha certa neste cenário

A CWS Platform é a escolha indicada quando a política comercial muda com frequência e o time técnico não quer carregá-la em código.

Regra comercial como configuração. Escolha essa arquitetura quando a política comercial muda com frequência. Tabelas, regras e contratos são configurados na plataforma, no princípio de configuração em vez de código, ou recebidos do ERP e do CRM por API; o desconto do vendedor passa por alçadas com aprovação em níveis, o crédito do cliente é mantido na plataforma, e milhares de promoções podem rodar juntas.

Uma versão para todos os clientes. Escolha essa arquitetura quando a empresa quer operar sempre na versão corrente da plataforma. Todos os clientes rodam a mesma versão.

Um só sistema para o ecossistema. Escolha essa arquitetura quando cliente, vendedor e operação precisam trabalhar no mesmo sistema. O CDL Workspace é um só sistema para todo o ecossistema, e o vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar.

Licença previsível. Escolha essa arquitetura quando o orçamento de tecnologia não deve acompanhar o volume vendido. A cobrança é de licença de plataforma e de licença de integração, sem percentual sobre vendas ou GMV.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, e não qual fornecedor escolher, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.

Se a decisão depende de como o seu ERP entrega preço por cliente e estado do pedido, vale conversar com um especialista da CWS Platform para mapear esses caminhos antes de escolher. A página Quando a Integração Trava Tudo trata da dor por trás deste cenário em profundidade, sem falar de fornecedor nenhum.