B2B portal for sales operations: commercetools or CWS Platform?

Editorial note: an architecture comparison between commercetools and CWS Platform for the scenario of a B2B portal used by the sales force, where sales reps and customers place orders in the same channel. The person who decides here is the CIO or CTO. Every fact about commercetools comes from its public documentation, with the address next to it.

Once the sales force starts entering orders in the B2B portal, the portal stops being a storefront and becomes part of sales operations. Every order a rep places has to reach the ERP, reflect the customer's credit, reserve inventory, and come back with a status for the person who sold it. An event that arrives twice becomes a duplicate order in billing. An event that arrives out of order becomes a cancellation processed before the order was created. And the rep finds out in front of the customer.

For whoever owns technology, the question in this scenario is less about the order API and more about the path between the platform and the company's systems: what delivery guarantees that path offers, where the code that runs along it lives, and who answers for it in production.

This comparison looks at commercetools and CWS Platform from that angle only. It is not a feature ranking. The overall map of models is in the post on the three B2B commerce platform models.

75s

What commercetools does well

commercetools offers a managed environment for integration code. Connect runs small applications in JavaScript, TypeScript, or Java without the customer needing its own infrastructure, and organizes them by type: Service, for synchronous actions through API Extensions or webhooks; Event, for processing asynchronous events through Subscriptions; Job, for scheduled tasks; plus Merchant Center extensions and static asset hosting.

The publishing cycle is explicit: a connector goes through a staged model, with preview builds and code and security validation, before becoming the published version ready for deployment. Publication can stay private to the project or go through certification into the Connect marketplace, and management can happen through the API, the Merchant Center, or the command line.

The same mechanism supports other pieces. In Checkout, communication with payment providers depends on public or custom connectors installed through Connect. For a sales portal, that means a standard way to package and deploy integrations, with the permissions of users in the buying account modeled in Associate Roles.

Where the architecture diverges

The divergence that matters to a CTO is in the guarantees of the event path and in where the integration code has to live. The vendor's own documentation records both points:

• limitation recorded in the vendor's documentation, accessed on October 16, 2026: Connect event delivery is at-least-once with no ordering guarantees ("The delivery promise is at-least-once delivery with no ordering guarantees.", https://docs.commercetools.com/connect/deployment-behavior-and-environments)
• limitation recorded in the vendor's documentation, accessed on October 16, 2026: the source code of Connect applications must be saved in a GitHub repository with a Git tag that refers to a specific 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)

The first record defines the engineering work on the customer's side. With at-least-once delivery and no guaranteed order, the same event can arrive more than once and related events can arrive swapped. The application that carries the order to the ERP has to recognize duplicates and reorder what matters. It is common practice in distributed systems, and the point is knowing that this code belongs to your team.

The second record defines the governance of that code. It lives in a GitHub repository with a release tag. The Connect documentation requires a connect.yaml file at the root with the configuration and, when the repository is private, read access for the connect-mu machine user. The sales portal integration gets a version cycle, reviews, and third-party access like any other software product in the company.

On CWS Platform, the platform is API-first and headless, with REST APIs and webhooks to notify the company's systems. Commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace), the customer's credit is maintained on the platform, and tax calculation can be delegated to the tax engine the customer already uses.

The technical decision is how much of sales operations will depend on integration code maintained by your team, and with what guarantees that code receives events.

What changes in sales operations with a B2B portal

Any ERP can represent a complex pricing rule. The bottleneck is distributing that rule to thousands of buyers and reps without training them on the ERP. The sales portal is what makes the rule distributable, which is why the path between the portal and the ERP becomes a critical piece of sales operations, not only of IT.

Three questions help bring this point into any evaluation. First: what delivery and ordering guarantees the event path offers, and which part of duplicate handling stays with your team. Second: where the integration code has to live, what outside access it requires, and how it fits your versioning and review routine. Third: how much commercial policy crosses that path on every order, and how much stays on the platform as parameters.

The third question shrinks the first two. The less commercial logic has to travel in events, the smaller the damage from a duplicate or out-of-order event.

On CWS Platform, one sales rep serves thousands of customers, and customer and sales rep use the same interface, on the same order. The order records who built the cart and who chose the payment, and the same order accepts more than one payment method, with the rules combined in CDL Workspace and maintained through an API. All customers run the same version of the platform.

When to choose commercetools

commercetools fits scenarios where integration engineering is an in-house competency:

A team that already runs event-driven systems. Choose this architecture when your team already designs idempotent consumers and knows how to handle at-least-once delivery, as recorded above, and wants a managed runtime such as Connect to host those applications.

Code governance centered on GitHub. Choose this architecture when the company already keeps integration code in GitHub repositories with release tags and reviews, and wants connector deployment to follow the same flow.

Packaged, reusable integrations. Choose this architecture when the company wants to publish private connectors or use certified connectors from the Connect marketplace, including for payments in Checkout.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when the sales portal needs API integration and commercial policy maintained as parameters on the platform.

Commercial policy that stays on the platform. Choose this architecture when pricing, promotions, and approval thresholds change often. Tables, rules, and contracts are configured on the platform, on the principle of configuration over code, or received from the ERP and CRM through an API, with customizable decimal places; thousands of promotions can run at the same time.

Credit and tax with a defined home. Choose this architecture when the customer's credit and tax need a defined place in the architecture. The customer's credit is maintained on the platform, granted in CDL Workspace or through an API, and tax comes from the ERP or from the tax engine the customer already uses.

Sales force and customer in the same system. Choose this architecture when the portal has to serve reps and buyers in the same system. CDL Workspace is a single system for the entire ecosystem, a sales rep builds a cart, with the items and the source of each one, and sends the link for the customer to complete, and the sales rep's discount goes through multi-level approvals.

A distributor's order, end to end. Choose this architecture when net-terms orders ship as split shipments, scheduled deliveries, to multiple ship-to addresses and from multiple ship-from locations, and the cart holds 250 line items by default, and that is configurable.

Where to go from here

If you want the comparison of the same vendor through the cost of keeping commercial rules integrated, the comparison commercetools or CWS Platform: what does it cost to keep commercial rules integrated? covers structure and lookup limits. If your question is still which architecture fits your operation, the path is the seven questions that separate B2B commerce architectures.

If the decision depends on how your ERP and CRM integration is designed, it is worth talking to a CWS Platform specialist to map which events your sales portal needs to exchange and where your commercial rules live today. The pages When Integration Breaks Everything and When Channels Fight Each Other cover the pain behind this scenario in depth, without talking about any vendor.