Portal B2B para força de vendas: commercetools ou CWS Platform?
Eventos at-least-once sem ordem garantida e código do Connect em repositório próprio, pela ótica de quem responde pela tecnologia.
Nota editorial: comparativo de arquitetura entre commercetools e a CWS Platform para o cenário de portal B2B usado pela força de vendas, em que vendedor e cliente fazem pedidos no mesmo canal. Quem decide aqui é o CIO ou CTO. Todo fato sobre commercetools vem da documentação pública dele, com o endereço ao lado.
Quando a força de vendas passa a registrar pedidos no portal B2B, o portal deixa de ser uma vitrine e vira parte da operação comercial. Cada pedido do vendedor precisa chegar ao ERP, refletir o crédito do cliente, reservar estoque e voltar com status para quem vendeu. Um evento que chega duas vezes vira pedido duplicado no faturamento. Um evento que chega fora de ordem vira cancelamento processado antes da criação. E o vendedor descobre isso na frente do cliente.
Para quem responde pela tecnologia, a pergunta desse cenário é menos sobre a API de pedido e mais sobre o caminho entre a plataforma e os sistemas da empresa: que garantias de entrega esse caminho dá, onde mora o código que o percorre e quem responde por ele em produção.
Este comparativo olha para commercetools e CWS Platform só por esse ângulo. Não é um ranking de funcionalidades. O mapa geral dos modelos está no post sobre os três modelos de plataforma de comércio B2B.
O que o commercetools resolve bem
O commercetools oferece um ambiente gerenciado para o código de integração. O Connect executa pequenas aplicações em JavaScript, TypeScript ou Java sem que o cliente precise de infraestrutura própria, e organiza essas aplicações por tipo: Service, para ações síncronas por API Extensions ou webhooks; Event, para processar eventos assíncronos por Subscriptions; Job, para tarefas agendadas; além de extensões do Merchant Center e hospedagem de arquivos estáticos.
O ciclo de publicação é explícito: o conector passa por um modelo de preparação, com builds de prévia e validação de código e segurança, antes de virar a versão publicada pronta para deploy. A publicação pode ficar privada para o projeto ou seguir para certificação e entrar no marketplace do Connect, e o gerenciamento pode ser feito por API, pelo Merchant Center ou por linha de comando.
O mesmo mecanismo sustenta outras peças. No Checkout, a comunicação com provedores de pagamento depende de conectores públicos ou customizados instalados pelo Connect. Para um portal de vendas, isso significa uma forma padronizada de empacotar e implantar integrações, com as permissões dos usuários da conta compradora modeladas em Associate Roles.
Onde a arquitetura diverge
A divergência que interessa ao CTO está nas garantias do caminho de eventos e em onde o código de integração precisa morar. A documentação do próprio fornecedor registra os dois pontos:
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: a entrega de eventos do Connect é at-least-once, sem garantia de ordem ("The delivery promise is at-least-once delivery with no ordering guarantees.", https://docs.commercetools.com/connect/deployment-behavior-and-environments)
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: o código das aplicações Connect precisa estar em um repositório GitHub com uma tag Git de release ("The source code of Connect applications must be saved in a GitHub repository and have a Git tag that refers to a specific release.", https://docs.commercetools.com/connect/overview)
O primeiro registro define o trabalho de engenharia do lado do cliente. Com entrega at-least-once e sem ordem garantida, o mesmo evento pode chegar mais de uma vez e eventos relacionados podem chegar trocados. A aplicação que leva o pedido ao ERP precisa reconhecer duplicatas e reordenar o que importa. É prática comum de sistemas distribuídos, e o ponto é saber que esse código é do seu time.
O segundo registro define a governança desse código. Ele vive num repositório GitHub com tag de release. A documentação do Connect pede um arquivo connect.yaml na raiz com as configurações e, quando o repositório é privado, acesso de leitura para o usuário de máquina connect-mu. A integração do portal de vendas passa a ter ciclo de versão, revisão e acesso de terceiros como qualquer produto de software da empresa.
Na CWS Platform, a plataforma é API-first e headless, com APIs REST e webhooks para avisar os sistemas da empresa. A política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace), o crédito do cliente é mantido na plataforma, e o cálculo de impostos pode ser delegado ao motor fiscal que o cliente já usa.
| decisão | commercetools, pelo mecanismo documentado | CWS Platform |
|---|---|---|
| Como os eventos chegam aos sistemas da empresa | Connect com entrega at-least-once, sem garantia de ordem; idempotência e ordenação ficam na aplicação do cliente | APIs REST e webhooks para avisar os sistemas da empresa |
| Onde mora o código de integração | Repositório GitHub com tag de release, com acesso para o usuário de máquina em repositório privado | Integração com ERP, CRM, fiscal e pagamentos por API, com a política comercial em parâmetros |
A decisão técnica é saber quanto da operação de vendas vai depender de código de integração mantido pelo seu time, e com que garantias esse código recebe os eventos.
O que muda na operação de vendas com portal B2B
Qualquer ERP consegue representar uma regra de preço complexa. O gargalo é distribuir essa regra a milhares de compradores e vendedores sem treiná-los no ERP. O portal de vendas é o que torna a regra distribuível, e por isso o caminho entre o portal e o ERP vira peça crítica da operação comercial, não só da área de tecnologia.
Três perguntas ajudam a levar esse ponto para qualquer avaliação. Primeira: que garantias de entrega e de ordem o caminho de eventos dá, e que parte do tratamento de duplicatas fica com o seu time. Segunda: onde o código de integração precisa morar, que acessos externos ele exige e como entra na sua rotina de versão e revisão. Terceira: quanto da política comercial atravessa esse caminho a cada pedido, e quanto fica parado na plataforma como parâmetro.
A terceira pergunta reduz o tamanho das duas primeiras. Quanto menos regra comercial precisa trafegar em evento, menor o estrago de um evento duplicado ou fora de ordem.
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, e o mesmo pedido aceita mais de um meio de pagamento, com as regras combinadas no CDL Workspace e mantidas por API. Todos os clientes rodam a mesma versão da plataforma.
Quando escolher o commercetools
O commercetools atende bem a cenários em que a engenharia de integração é uma competência da casa:
Time que já opera sistemas orientados a eventos. Escolha essa arquitetura quando o seu time já desenha consumidores idempotentes e sabe tratar entrega at-least-once, como registrado acima, e quer um runtime gerenciado como o Connect para hospedar essas aplicações.
Governança de código centralizada no GitHub. Escolha essa arquitetura quando a empresa já mantém o código de integração em repositórios GitHub com tags de release e revisão, e quer que o deploy dos conectores siga esse mesmo fluxo.
Integrações empacotadas e reaproveitáveis. Escolha essa arquitetura quando a empresa quer publicar conectores privados ou usar conectores certificados do marketplace do Connect, inclusive para pagamentos no Checkout.
Quando a CWS Platform é a escolha certa neste cenário
A CWS Platform é a escolha indicada quando o portal de vendas precisa de integração por API e da política comercial mantida em parâmetros na plataforma.
Política comercial parada na plataforma. Escolha essa arquitetura quando preço, promoção e alçada mudam 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, com casas decimais customizáveis; milhares de promoções podem rodar juntas.
Crédito e imposto com lugar definido. Escolha essa arquitetura quando o crédito do cliente e o imposto precisam de um lugar definido na arquitetura. O crédito do cliente é mantido na plataforma, concedido no CDL Workspace ou por API, e o imposto vem do ERP ou do motor fiscal que o cliente já usa.
Força de vendas e cliente no mesmo sistema. Escolha essa arquitetura quando o portal precisa servir vendedor e comprador no mesmo sistema. O CDL Workspace é um só sistema para todo o ecossistema, o vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar, e o desconto do vendedor passa por alçadas com aprovação em níveis.
Pedido de distribuidor de ponta a ponta. Escolha essa arquitetura quando o pedido a prazo sai com entrega fracionada, agendada, em vários endereços e a partir de várias origens, e o carrinho comporta 250 itens por padrão, configurável.
Por onde continuar
Se você quer a comparação do mesmo fornecedor pelo custo de manter a regra integrada, o comparativo commercetools ou CWS Platform: quanto custa manter a regra comercial integrada? trata dos limites de estrutura e de consulta. Se a sua pergunta ainda é qual arquitetura serve à sua operação, 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 que eventos o seu portal de vendas precisa trocar e onde a sua regra comercial mora hoje. As páginas Quando a Integração Trava Tudo e Quando os Canais Brigam Entre Si tratam da dor por trás deste cenário em profundidade, sem falar de fornecedor nenhum.
Leia também
Marcas citadas neste artigo
Marcas e logotipos pertencem aos seus titulares. A citação não indica parceria nem endosso.
"Estavamos á quase 2 anos tentando implantar uma solução B2B, com a CWS, implantamos em 60 dias."
Quer ver isso na sua operação?
Operações B2B reais já rodam nisso.