commercetools ou CWS Platform: quanto custa manter a regra comercial integrada?

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

Quem responde pela tecnologia de um distribuidor costuma avaliar uma plataforma de comércio pelo desenho das APIs. A pergunta que pesa no terceiro ano é outra: quanto custa manter tudo integrado quando a operação cresce, e quem escreve o código que liga a regra comercial ao pedido.

Há dois desenhos em jogo. Em um, a plataforma entrega blocos de API bem definidos, e o time do cliente monta sobre eles a regra comercial, o front-end e as integrações. No outro, a regra comercial já vive na plataforma como configuração, e a integração com ERP e CRM leva e traz dados, sem carregar a política de preço.

Este comparativo olha para commercetools e CWS Platform só por esse ângulo: onde mora a regra, o que o time técnico precisa construir e manter, e o que a documentação diz sobre os limites de cada peça. Não é um ranking de funcionalidades.

72s

O que o commercetools resolve bem

Para o B2B, o commercetools modela a empresa compradora com Business Units do tipo Company e Division, com herança de lojas, papéis e regras de aprovação das unidades superiores para as de baixo.

A aprovação de compra é declarativa: as Approval Rules combinam critérios do pedido (moeda, país, valor total) com papéis de quem pede e de quem aprova, e a plataforma gera o fluxo de aprovação quando um pedido casa com a regra. A negociação tem objetos próprios, do pedido de cotação à proposta vinculante, descritos na visão geral de Quotes.

No preço, os Standalone Prices ficam fora do documento do produto e são selecionados por país, moeda, canal, grupo de clientes e validade, o que acomoda grande volume de preços por variante. O sortimento por cliente ou canal sai de Product Selections associadas a lojas. Para quem tem um time de engenharia que quer escolher cada peça, esse conjunto é uma base sólida.

Onde a arquitetura diverge

A divergência que interessa ao CTO está em quem carrega a regra e a integração. No commercetools, a regra comercial é expressa em objetos de API, como preços, regras de aprovação e cotações. O front-end pode usar o commercetools Frontend, oferecido como SaaS, ou o Store Launchpad for B2B Manufacturing, um template que é copiado para o projeto do cliente e cuja manutenção fica com o desenvolvedor.

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

• limitação registrada na documentação do fornecedor, consultada em 16/10/2026: a hierarquia de Business Units é limitada a 5 níveis; um Import Request pode conter no máximo 20 recursos para importar ("The hierarchy of Business Units is limited to 5 levels.", "An Import Request may contain a maximum of 20 resources to import.", https://docs.commercetools.com/api/limits).
• limitação registrada na documentação do fornecedor, consultada em 16/10/2026: apenas pedidos dos últimos 3 meses são indexados e podem ser recuperados pela Order Search; a Order Search API é desativada automaticamente se não houver chamadas ao endpoint nos últimos 30 dias ("Only Orders from the last 3 months are indexed and can be retrieved.", "The Order Search API is automatically deactivated for a Project if there have been no calls to the Search Orders endpoint in the last 30 days.", https://docs.commercetools.com/api/projects/order-search).

O limite de níveis é tratado pelo fornecedor como ajustável por projeto, depois de análise técnica. Mesmo assim, ele mostra o desenho: a estrutura do cliente, a carga em lote e a consulta histórica de pedidos são preocupações que o time de integração precisa planejar.

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. Todos os clientes rodam a 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 peças que o seu time escreveu entre o sistema de registro e o comprador. Quando a regra comercial depende de orquestração própria, cada mudança de política de preço, de alçada ou de sortimento tende a virar item de backlog técnico, com teste e publicação.

Três perguntas ajudam a levar esse ponto para qualquer avaliação: quais regras comerciais o time vai precisar codificar fora da plataforma; quais limites documentados a carga em lote e a consulta de pedidos impõem ao desenho; e quem mantém o front-end e os conectores quando a plataforma muda.

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. O carrinho comporta 250 itens por padrão, configurável. 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 commercetools

O commercetools atende bem a cenários em que a composição da arquitetura é o objetivo:

Time de engenharia dedicado a uma arquitetura composta. Escolha essa arquitetura quando a empresa tem um time próprio de engenharia que quer escolher e manter cada peça, do front-end aos conectores, sobre APIs bem documentadas como as de Business Units e Approval Rules.

Grande volume de preços por variante e por canal. Escolha essa arquitetura quando a operação precisa manter muitos preços por SKU, segmentados por canal, grupo de clientes e validade, como os Standalone Prices permitem.

Negociação formal por objetos de cotação. Escolha essa arquitetura quando a empresa quer o ciclo de negociação em objetos de API separados (Quote Request, Staged Quote e Quote), como descrito na visão geral de Quotes.

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.

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.

Venda a prazo com operação real de distribuidor. Escolha essa arquitetura quando a venda a prazo precisa conviver com entrega fracionada, agendada, em vários endereços e a partir de várias origens. O mesmo pedido aceita mais de um meio de pagamento, com as regras combinadas no CDL Workspace e mantidas por API.

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 do desenho da sua integração com ERP e CRM, vale conversar com um especialista da CWS Platform para mapear onde a sua regra comercial mora hoje. As páginas Quando a Integração Trava Tudo e Quando o Catálogo Vira Caos tratam da dor por trás deste cenário em profundidade, sem falar de fornecedor nenhum.