Pagination and limits

limit and offset

Listings paginate with two query parameters: limit, the number of records per page, and offset, how many records to skip. Order and contract listings come from newest to oldest.

The default and the cap of limit change per endpoint. Above the cap, the cap applies, with no error.

Date filters on orders

Order listings accept createdFrom, createdTo, updatedFrom and updatedTo, in ISO-8601, and the status filter, which can be repeated. That is what enables incremental polling: asking only for what changed since the last read.

The end of a list is not always an empty page

Three behaviors documented in the collection depart from the pattern and need their own handling.

• Orders: with no result, the response is an empty array.
• Cashback balance by customer: there is no empty page. When offset goes past the last entry, the response is 400 with no record found, and that 400 is what ends pagination.
• Credit limits: with results the response is an array; with none, it is an empty object. Iterating straight over the response breaks in the empty case.

Batch size

There are two routes for sending inventory and price in bulk. They coexist, and each one serves a different rhythm.

• PUT /v1/stock/batch: 1 to 50 items per request, with each item's result in the response. This is the route for continuous updates. An empty batch or one above 50 items is rejected with 422.
• POST /api/v1/stocks/batch: up to 200 items per request, processed in an asynchronous queue. This is the route for large loads. It is not in the public collection, so it has no reference page in this area.

Source for the second route: the CWS Platform knowledge base, confirmed by the technology team on October 6, 2026.

Rate limits

The public collection does not publish a rate limit. If your integration design depends on that number, confirm it with the integration team at suporte-api@cws.digital before sizing the load.