Spryker or CWS Platform: Where Does Customer Pricing Travel in the ERP Integration?

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

A platform where part of the processes, such as the order lifecycle, is modeled in the project's code tends to appeal to technology leaders at distributors. The math shows up later: that code becomes your team's to own, and every ERP integration needs an API path that covers the data the business actually uses.

There are two designs in play. In one, the customer's team maintains the code for part of the processes in the project. In the other, the distributor's commercial rules already live in the platform as configuration, and the integration moves data in and out without carrying pricing policy.

This comparison looks at Spryker and CWS Platform from that angle only: what the technical team builds, which path the integration takes, and what the documentation says about the API paths. It is not a feature ranking.

What Spryker does well

Spryker brings ready-made B2B features for modeling the buying company. Company Account organizes the company into business units and users, with roles and permissions that restrict or extend access to products and orders.

Contract pricing comes in through Merchant Custom Prices, where the merchant relationship is a price dimension alongside mode, volume, store, and currency. The order lifecycle is modeled in state machines configured per project, as described in the Order Management System guide, which gives the technical team fine-grained control over each step.

For procurement-driven buying, the PunchOut Gateway implements OCI and cXML flows with eProcurement systems. For a company with an engineering team that wants to control the code of every process, this is a solid foundation.

Where the architecture diverges

The divergence that matters to a CTO is the path the integration takes. In Spryker, the APIs are split by actor and usage pattern: Storefront API, Back Office API, Merchant API, and the Data Exchange API for bulk data operations. The order lifecycle is modeled in state machines configured in the project, and contract prices are entered in the Back Office or the Merchant Portal.

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

• limitation recorded in the vendor's documentation on July 30, 2026: the Data Exchange API supports neither customer-specific pricing nor Order Management System operations ("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).
• limitation recorded in the vendor's documentation on July 30, 2026: Glue gets bugfixes, security and compatibility, but no new 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).

For a distributor, customer-specific pricing and order status are exactly the data that flow most often between the ERP and the portal. When the bulk API does not cover them, the technical team designs another path for them, and that path becomes part of what has to be maintained.

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, and 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 data paths your team wrote and has to keep up with. Customer-specific pricing, order status, credit, and inventory by ship-from location are the data that change every day in distribution, and each one needs a round trip to the ERP.

Three questions help bring this point into any evaluation: which commercial data the bulk API covers and which it leaves out; which part of the order logic lives in the project's code; and who migrates the integrations when the API the project uses stops evolving.

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. 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 Spryker

Spryker fits scenarios where control over the code is the goal:

An engineering team that wants to control every process. Choose this architecture when the company has its own team that wants to model the order lifecycle in state machines and maintain that code, as described in the Order Management System guide.

Procurement-driven buying. Choose this architecture when buyers order through OCI or cXML and the store needs to respond to those systems, as the PunchOut Gateway does.

A buying-company structure with fine-grained permissions. Choose this architecture when the operation needs business units, users, and roles with detailed permissions, as in Company Account.

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 version for every customer. Choose this architecture when the company wants to always run on the current version of the platform. All customers run the same version.

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.

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 delivers customer-specific pricing and order status, it is worth talking to a CWS Platform specialist to map those paths before you choose. The page When Integration Breaks Everything covers the pain behind this scenario in depth, without talking about any vendor.