Skip to content
platform

Use cases

B2B customer portal: the typical path through the API

Scenario

The company opens a portal where the B2B customer signs in and buys alone, on the terms already negotiated with them. The portal only replaces the phone if it shows the buyer the price, credit and inventory that apply to them, not a general price list.

In B2B the price is not a stored value: it is the result of rules that consider who is buying, where the product ships from, the quantity and the payment terms. That is why the integration brings the links and the rules to the portal (customer groups, contracts, price rules, credit limit), and the platform calculates the price at the moment of purchase.

The sales rep stays in the channel. They serve customers inside the same portal, on the customer's terms, and an order can start with one and finish with the other.

The pains that lead to this integration

Each customer's negotiated price does not fit in the portal

How it shows up

"Every customer has their own price, and nobody can get that onto the site."

Why it happens

A B2B transaction moves five variables at once (price, delivery, payment, quantity and composition), and ecommerce platforms treat them as static form fields.

The customer gives up at checkout because there is no invoice on terms

How it shows up

"The customer puts everything in the cart and gives up at checkout because there is no invoice on terms."

Why it happens

B2B payment is a financial service: invoiced terms, a credit limit used as payment, barter and splitting the amount between sellers. A checkout designed for credit cards cannot hold that.

We simplified pricing because the system cannot handle it

How it shows up

"We flattened the price list because keeping a different price per branch and per customer became impossible to manage."

Why it happens

The source system cannot sustain price by warehouse crossed with the price of each customer, each category and each condition, and the company flattens the policy to be able to manage it.

My sales reps say the portal will kill their commission

How it shows up

"My sales reps say the portal will kill their commission."

Why it happens

If the sales rep is only paid for manual orders, the portal means lost commission, and the resistance is rational. It is a flaw in the operating model, not in the platform.

What is usually integrated

EntityDirectionTypical frequencyEndpoints and events
Customers, addresses and groups The customer's group is one of the criteria that price rules and payment terms use to decide what applies to them. Both directions Initial load and on every registration change
Price contracts The contract fixes the item price for the linked customers and overrides price rules. Among contracts valid for the same customer, the one with the lowest priority number applies. Your system to CWS Platform Per contract term
Price rules Among non-cumulative rules only the highest-priority one applies; cumulative rules are applied on top of the result. Your system to CWS Platform When commercial policy changes
Credit limit The limit is a customer current account on the platform, with balance and statement, and can be used as a payment method. Your system to CWS Platform On every financial event that changes the limit
Inventory and price by warehouse Each product and warehouse pair has its own price and quantity, and shipping is calculated from the address of the origin warehouse. Your system to CWS Platform Continuous, in small batches
Sales reps and portfolios Your system to CWS Platform When the portfolio changes
Product priority in search Each product can have a priority level in the store's searches, from 1 to 5. Once the priority is removed, the product goes back to the default search behavior. Your system to CWS Platform When the priority assortment changes
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
Products, shipping and payment methods Product registration, shipping tables and payment terms are maintained in the panel. The knowledge base also describes product creation and inventory lookup through the API: this is not in the public collection. Configured in the panel At rollout and when the operation 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

    Load customers and groups

    Your system creates the customers on the platform, with their addresses, and links them to the groups the commercial policy uses. The customer document is the key in the calls that follow.

  3. 3

    Publish contracts and price rules

    Your system sends the contracts, with each one's customers and products, and the price rules. For whoever is linked to a contract the contract price applies; outside its conditions the store's standard price applies, with the applicable price rules.

  4. 4

    Send inventory and price

    Your system sends inventory and price by warehouse, in batches of 1 to 50 items. The response carries each item's result, so the integrator reads the body and reprocesses only what was rejected.

  5. 5

    Report the credit limit

    Your system reports each customer's limit. From then on an order with enough balance is approved automatically, and the customer closes the purchase on terms without waiting for a separate release.

  6. 6

    Your system registers the sales reps and builds each one's portfolio. When serving, the rep buys on behalf of the customer with that customer's addresses, credit limit, contract prices and price rules.

  7. 7

    Receive the order and report progress

    After the order is generated, the platform notifies your endpoint by webhook. Your system fetches the full order, records it and reports each stage: ready to ship, shipped with tracking, and the invoice already issued.

Variations

Your system builds a cart with products chosen for a customer and receives the access link. The customer opens the link and completes the purchase with the items already in place.

Several branches

When a head office integrates on behalf of several branches, each branch's inventory and contracts have their own routes, with the branch in the path. The credit limit can apply per store or to the whole head office; in that case the customer uses the limit at any branch.

Order above the credit limit

When the customer has no balance, the store decides by configuration whether they can close the order and leave it pending approval. An order that exceeds the limit is created with its own initial status, generated by the platform.

Quote for an item with no price or no stock

A product can stay on the portal with quoting enabled even with no price or stock. The customer requests the quote, and your system lists the pending requests and answers with price and lead time.

Your system sets a product's priority level in the store's searches and adjusts it when the priority assortment changes.

Taxes calculated in the ERP

Depends on activation

When the tax rule lives in the ERP, the platform calls the ERP's tax endpoint before closing the order and uses the returned values, per item. It is a synchronous call, and its response time becomes part of the cart's time.

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.