Skip to content
platform
EN PT

Use cases

Ecommerce ERP integration: the typical path through the API

Scenario

The company already has an ERP, and that is where registration data, inventory, tax and finance live. CWS Platform comes in as the layer where the customer and the sales rep negotiate and close the order. The integration exists so both sides work with the same data without retyping.

In the most common design the ERP remains the system of record. It sends the platform what the channel needs to show (inventory, price, customers, credit limit, contracts) and receives back what the channel produces (orders), then reports the progress of each order: status, invoice and tracking.

The platform does not issue the invoice. It receives from the ERP the data and the XML of the invoice already issued.

The pains that lead to this integration

The portal shows inventory and prices that differ from the ERP

How it shows up

"The portal shows inventory that no longer exists."

Why it happens

The ERP works in processing windows, and the truth of the system of record does not reach the sales channel at the pace the customer buys.

The ERP is forced to serve the sales channel in real time

How it shows up

"Every simple change becomes an IT project."

Why it happens

The ERP was designed to record. When it also has to answer the customer on the spot, every new commercial rule becomes development inside the system that holds tax and accounting.

Every change in commercial policy becomes an integrator project

How it shows up

"To create a new discount rule I open a ticket, the integrator quotes, develops and tests, and the campaign is already over."

Why it happens

Each customer's price, approval levels, credit and tax rules are developed in the project, outside the product, and each customization has to be maintained and retested on every policy change.

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.

What is usually integrated

EntityDirectionTypical frequencyEndpoints and events
Inventory and price Two possibilities: the collection route, 1 to 50 items with a per-item response, for continuous updates; and POST /api/v1/stocks/batch, up to 200 items in an asynchronous queue, for large loads. The second one is not in the public collection. Source for the second route: the CWS Platform knowledge base, confirmed by the technology team on October 6, 2026. ERP to CWS Platform Continuous, in small batches; large loads as a queue
Customers and addresses Both directions Initial load and on every registration change
Customer groups ERP to CWS Platform When commercial segmentation changes
Credit limit On the platform the limit is a customer current account, with balance and statement. ERP to CWS Platform On every financial event that changes the limit
Price contracts The contract fixes the item price for the linked customers; outside the contract conditions the store's standard price applies. ERP to CWS Platform Per contract term
Price rules ERP to CWS Platform When commercial policy changes
Orders CWS Platform to ERP Per event (webhook) or by periodic polling
Status, invoice and tracking Ready to ship requires the ERP order number; the invoice data can go along, and the operation can configure it as mandatory in the sales process; shipped carries the tracking; canceled requires the cancellation reason. ERP to CWS Platform On every order stage change in the ERP
Taxes per item CWS Platform to ERP On every calculation, before closing the order (depends on activation)

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

    The ERP 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

    Send inventory and price

    For continuous updates, the ERP sends inventory and price 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. For large loads there is a second route, POST /api/v1/stocks/batch, with up to 200 items per request and asynchronous queue processing; it is not in the public collection. Inventory sent through the API automatically reactivates a product that was off sale.

  4. 4

    Publish the commercial terms

    The ERP reports each customer's credit limit and the price contracts, with the customers and products of each contract. From then on an order with enough balance is approved automatically, and the contract price applies to whoever is linked to it.

  5. 5

    Receive the order

    After the order is generated, the platform notifies your endpoint by webhook. The ERP fetches the full order with the identifier received and records it. The initial order statuses are generated by the platform, and the integration moves the order on from them.

  6. 6

    Report progress

    As the order moves in the ERP, the integrator updates the status on the platform: ready to ship, with the ERP order number, and shipped, with the tracking. Cancellation requires the reason. The flow is one-way: a shipped order does not go back to ready to ship. The XML of the issued invoice is sent through the invoice endpoint.

  7. 7

    Reconcile

    Periodic polling of the order listing by update date checks that the ERP has everything the platform generated, and recovers what the webhook did not deliver.

Variations

Head office with 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 branch must be linked to the token's head office; without the link the response is 403.

Marketplace operation

In a marketplace, the store that sold is the one that updates the status of its own order, and the marketplace operator queries every order in its environment through its own routes. One customer order can generate more than one supplier order.

No webhook, polling only

Whoever does not yet have an endpoint to receive webhooks integrates orders by polling only: list orders by status and by update date and fetch the detail of each one.

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.

Quote answered by the ERP

When the customer requests a quote, the integrator lists the pending quotes, answers with price and terms from the ERP and follows the quote that became an order.

Lead time on request

For items with lead time on request, the integrator lists the order items waiting for a lead time and reports each one's lead time from the ERP.

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.