Skip to content
platform

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

EntityDirectionTypical frequencyEndpoints 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. 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.

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

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

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

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

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 architect

Platform modules involved

Generated from the public API collection, published on 2026-09-04: api-docs.cws.digital.