commercetools or CWS Platform: What Does It Cost to Keep Commercial Rules Integrated?

Editorial note: an architecture comparison between commercetools and CWS Platform, written for those who answer as CTO. Every fact about commercetools comes from its public documentation, with the address next to it.

Technology leaders at distributors usually evaluate a commerce platform by the design of its APIs. The question that weighs in year three is a different one: what does it cost to keep everything integrated as the business grows, and who writes the code that connects commercial rules to the order?

There are two designs in play. In one, the platform delivers well-defined API building blocks, and the customer's team builds commercial rules, the front end, and the integrations on top of them. In the other, commercial rules already live in the platform as configuration, and the ERP and CRM integrations move data in and out without carrying pricing policy.

This comparison looks at commercetools and CWS Platform from that angle only: where the rules live, what the technical team has to build and maintain, and what the documentation says about the limits of each piece. It is not a feature ranking.

73s

What commercetools does well

For B2B, commercetools models the buying company with Business Units of type Company and Division, with stores, roles, and approval rules inherited from parent units down to child units.

Purchase approval is declarative: Approval Rules combine order criteria (currency, country, total price) with requester and approver roles, and the platform creates the approval flow when an order matches a rule. Negotiation has its own objects, from the quote request to the binding quote, as described in the Quotes overview.

On pricing, Standalone Prices sit outside the product document and are selected by country, currency, channel, customer group, and validity, which accommodates a large number of prices per variant. Assortment by customer or channel comes from Product Selections assigned to stores. For a company with an engineering team that wants to pick every piece, this is a solid foundation.

Where the architecture diverges

The divergence that matters to a CTO is who carries the rules and the integration. In commercetools, commercial rules are expressed in API objects such as prices, approval rules, and quotes. The front end can use commercetools Frontend, offered as SaaS, or the Store Launchpad for B2B Manufacturing, a template that is copied into the customer's project and maintained by the developer.

The vendor's own documentation records limits that enter the math of whoever designs the integration:

• limitation recorded in the vendor's documentation, accessed on October 16, 2026: the hierarchy of Business Units is limited to 5 levels; an Import Request may contain a maximum of 20 resources to import ("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).
• limitation recorded in the vendor's documentation, accessed on October 16, 2026: only orders from the last 3 months are indexed and can be retrieved through Order Search; 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 ("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).

The vendor treats the level limit as adjustable per project after a technical review. Even so, it shows the design: the customer's account structure, batch loading, and historical order lookups are concerns the integration team has to plan for.

On CWS Platform, commercial rules sit in parameters of the Commerce Rules Engine (CDL Workspace): price tables, rules, and contracts are configured on the platform and can also arrive from the ERP or CRM through an API, with customizable decimal places. The platform is API-first and headless, with REST APIs and webhooks to notify the company's systems. All customers run the same version of the platform.

The technical decision is whether the distributor's commercial policy becomes code maintained by your team or parameters maintained through configuration on the platform.

What changes in operations, through the CTO lens

The cost of staying integrated grows with the number of pieces your team wrote between the system of record and the buyer. When commercial rules depend on custom orchestration, every change to pricing policy, discount approvals, or assortment tends to become a technical backlog item, with testing and deployment.

Three questions help bring this point into any evaluation: which commercial rules your team will have to code outside the platform; which documented limits batch loading and order lookups place on the design; and who maintains the front end and the connectors when the platform changes.

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. The cart holds 250 line items by default, and that is configurable. Integration with ERP, CRM, tax, and payments is through APIs, and tax calculation can be delegated to the tax engine the customer already uses.

When to choose commercetools

commercetools fits scenarios where composing the architecture is the goal:

A dedicated engineering team for a composed architecture. Choose this architecture when the company has its own engineering team that wants to select and maintain every piece, from the front end to the connectors, on well-documented APIs such as Business Units and Approval Rules.

A large number of prices per variant and per channel. Choose this architecture when the operation needs to maintain many prices per SKU, segmented by channel, customer group, and validity, as Standalone Prices allow.

Formal negotiation through quote objects. Choose this architecture when the company wants the negotiation cycle as separate API objects (Quote Request, Staged Quote, and Quote), as described in the Quotes overview.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when commercial policy changes often and the technical team does not want to carry it in code.

Commercial rules as configuration. Choose this architecture when commercial policy changes 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; the sales rep's discount goes through multi-level approvals, the customer's credit is maintained on the platform, and thousands of promotions can run at the same time.

One system for the whole ecosystem. Choose this architecture when customers, sales reps, and operations need to work in the same system. CDL Workspace is a single system for the entire ecosystem, and a sales rep can build a cart, with the items and the source of each one, and send the link for the customer to complete the purchase.

Net terms that match how distributors actually ship. Choose this architecture when net terms have to coexist with split shipments, scheduled deliveries, multiple ship-to addresses, and multiple ship-from locations. The same order accepts more than one payment method, with the rules combined in CDL Workspace and maintained through an API.

Predictable licensing. Choose this architecture when the technology budget should not track the volume you sell. Billing is a platform license plus an integration license, with no percentage of sales or GMV.

Where to go from here

If your question is still which architecture fits your operation, and not which vendor to choose, 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 where your commercial rules live today. The pages When Integration Breaks Everything and When the Catalog Becomes Chaos cover the pain behind this scenario in depth, without talking about any vendor.