Use cases
Guided selling and counter sales: the typical path through the API
Scenario
The sales rep and the counter serve inside the portal itself: they identify the customer and buy on their behalf, with that customer's addresses, credit limit, contract prices and price rules. The customer does not need to sign in to the portal to be served.
The quote stops being a separate document. The cart the rep builds already uses the customer's terms, and becomes an order when the customer accepts, with no retyping. The rep saves the cart and sends the link; the customer edits it, closes alone or hands it back for the rep to complete.
In a real negotiation, discount and payment terms are traded for one another. That is why both are limited in the same place: each rep's discount authority and the payment terms allowed for each customer group.
The integration maintains, from your system, who the sales reps are, which customers each one serves and the carts that arrive ready-made.
The pains that lead to this integration
Approving discounts is chaos; everyone approves their own way
How it shows up
"Approving discounts is chaos. Everyone approves their own way."
Why it happens
There are no approval limits in the system, with preventive blocking. Approval is human, informal and not auditable.
Gross margin looks fine, but net margin does not
How it shows up
"My gross margin looks fine, but my net margin does not."
Why it happens
Three sources combined: stacked discounts, no audit trail or approval limits, and after-sales (returns, exchanges and reverse shipping), all outside the gross margin report.
The opportunity only shows up if the sales rep goes after it
How it shows up
"My revenue depends on every sales rep remembering to call the right customers."
Why it happens
Generating opportunities is an individual, uninstrumented act: it depends on each rep's memory, discipline and willingness, and there is no system that goes through the whole portfolio looking for what to offer to whom.
What is usually integrated
| Entity | Direction | Typical frequency | Endpoints and events |
|---|---|---|---|
| Sales reps The sales rep is registered from an account that already exists, with the permissions they will have when serving. Once the rep is removed, the account still exists. | Your system to CWS Platform | When the team changes |
|
| Each rep's customer portfolio The bulk portfolio call links, unlinks or replaces the customer list in a single request. | Your system to CWS Platform | When the portfolio changes | |
| Customers | Both directions | Initial load and on every registration change | |
| Contracts and price rules Rules and contracts have the option of preventing the sales rep from applying an additional discount on the resulting price. | Your system to CWS Platform | Per contract term and when policy changes |
|
| Credit limit | Your system to CWS Platform | On every financial event that changes the limit | |
| Carts built by your system The cart can carry the email of the responsible sales rep. Once the cart is deleted, the link stops working. | Your system to CWS Platform | On every offer prepared for a customer |
|
| Quotes | Both directions | On every customer request |
|
| Orders | CWS Platform to your system | Per event (webhook) or by periodic polling |
|
| Status, invoice and tracking The platform does not issue the invoice: it receives the data and the XML of the invoice already issued. The status flow is one-way. | Your system to CWS Platform | On every order stage change | |
| Discount authority and approval Each sales rep has three limits: the authority, above which the order goes to approval; the item block, which prevents entering the discount on the line; and the order block. When sending for approval, the rep states the reason. This is not in the public collection. | Configured in the panel | When discount policy changes | |
Typical flow
- 1
Authenticate
The integrator gets the access token with the store's integration user and sends it as Bearer on every other call. The token lasts 12 hours; when it expires the response is 401 and you simply authenticate again.
- POST Get Access Token
- 2
Register the sales reps
Your system registers each sales rep from an account that already exists and sets their permissions when serving, such as limiting the rep to their own portfolio.
- POST Add Sales Rep
- GET List Sales Reps
- 3
Build the portfolios
Your system links each rep's customers, one by one or in bulk. From the link on, the customer is served by that rep.
- 4
Make sure the customer's terms are in place
Serving uses what the customer already has on the platform. Your system maintains the registration, the price contracts and the credit limit, and those are what the rep negotiates with.
- 5
Deliver ready-made carts
Your system builds a customer's cart, names the responsible sales rep and receives the access link, to send to the customer. The customer opens the link and completes the purchase with the items already in place.
- POST Create Custom Cart
- PUT Edit Custom Cart
- 6
Receive the negotiated order
A discount above the rep's authority sends the order to approval before it moves on. After the order is generated, the platform notifies your endpoint by webhook, and your system fetches the full order.
- GET Get Order Details - Store
- Webhook Orders webhook
- 7
Report progress
Your system updates the order status and sends the invoice already issued. While the order is pending approval, the status update returns 422.
Variations
One sales rep per customer
By default a customer can accumulate sales reps. The link can be made unique, replacing the previous rep, and the store can require each customer to be tied to a single rep.
Shipping negotiated by the sales rep
Depends on activation
The sales rep's registration defines whether they can change shipping or enter a shipping option. With the shipping authority active, the change has its own limit and a blocking ceiling, and requires a reason.
- POST Add Sales Rep
Multi-level approval
Depends on activation
Each profile has a discount range it approves, and the order moves up level by level, with comments and history. It is configuration, with no route in the public collection.
Authority validated by an external engine
Depends on activation
The store can choose which stores have the discount authority validated by an external mechanism, on your side. This is not in the public collection.
Quote answered by your system
When the customer requests a quote, your system lists the pending requests and answers with price and lead time. When the quote becomes an order, the integration traces which quote it came from.
Counter sale made outside the platform
Depends on activation
When the counter still closes the sale in another system, your system can report that sale to the cashback program, and the credit is kept for use on the portal.
Range of possibilities
This is a common path, not the only one.
CWS Platform reaches the same goal through configuration, through the API or through a combination of the two, and the best approach depends on your operation, your ERP and your rules. Talk to a CWS Platform architect to design the integration for your case.
Talk to an architectPlatform modules involved
- Guided Selling: the sales rep and the counter in the same portal
- Sales Hub: sales reps, portfolios and authority limits
- CDL Workspace: where authority and approval are configured
- Pricing Engine: contracts, rules and the additional-discount lock
- Checkout & Payments: credit and payment terms by group
- OMS: the negotiated order and its progress
Read on the blog
- What Is an Approval Matrix and How to Structure Discount Tiers
- Off-Policy Discounting: How to Know If Your Sales Reps Are Giving It Away Behind Your Back
- A Quote Is a Proposal Against Your Rules: Why Your Margin Already Leaked by the Time the Rep Names a Price
- B2B Account Activation in Wholesale: Why Reorders Stall When Reps Control the Order
Generated from the public API collection, published on 2026-09-04: api-docs.cws.digital.