Pagination

The v10 list endpoints (orders, invoices, credit notes, shipments, customers, customer groups, products, variants, inventory available, accounting entries, production orders and production order delivery notes) are paginated with cursors. Performance stays constant no matter how deep you paginate.

Use limit to control the page size. If no limit is given a default of 20 is used. Max limit is 100.

Inventory available is cursor-only: it does not support the page parameter and never returns totals — walk it with limit + cursor / starting_after.

Every list response includes two pagination fields:

Field	Data type	Description
has_more	boolean	Whether more rows exist after the last row of this page
next_cursor	string or null	Opaque token pointing at the last row of this page. null when has_more is false

To paginate, request the first page and follow next_cursor until has_more is false:

GET /v10/orders?limit=100
GET /v10/orders?limit=100&cursor={next_cursor from the previous response}

When cursor is given the response does not include totals — use has_more instead.

Resuming an id walk with starting_after

For the default sorting (id ascending) you can skip the cursor token and pass the last id you processed directly. This also makes it trivial to resume an interrupted export:

GET /v10/orders?limit=100&starting_after=3435177

starting_after only works with the default sorting. Combine it with a custom sort and the API returns a validation error.

Cursor pagination with sorting

Cursors work with sorting, with two constraints:

• Each v10 list endpoint supports a small set of sort keys, and other sort keys are rejected with a validation error. All list endpoints support id (the default). Orders and invoices additionally support updated_at; shipments additionally support created_at.
• The sort parameter must be identical on every request of a walk. The cursor encodes the sorting it was created for, and the API rejects a cursor used with a different sort.

The API automatically adds id as a final tiebreaker to the sorting, so rows with identical sort values (for example the same created_at timestamp) are never skipped or repeated between pages.

Product pagination (used sometimes)

Some endpoints, specifically surrounding fetching products, can have inconsistent pagination. What this means is that you cannot count the number of products returned to be consisting on every page. This is because some brands setup their products in a way where 1 product can be returned as multiple products.

note

We will mark in the API reference when product pagination is used

An example would be Product 001 which comes in 3 colors: Black, White, Blue. In Traede this is created as a single product with multiple colors. However, the brand wants this to be displayed as 3 separate products on their B2C channel. Therefore, the order channel API will return this as 3 products instead of one. This can mess up pagination. Therefore, for endpoints that uses this pagination you should fetch products using a while loop until the API does not return any more products. Here is an example of how that looks written in PHP.

note

This is pseudo-code that assumes you have a variable $client that holds some sort of class that can communicate with the Traede API

<?php

$results = [];

$currentPage = 0;
$limit = 20;
while(true) {
    $result = $client->request('GET', sprintf('https://api.traede.com/3pl/products?page=%s&limit=%s', $currentPage, $limit));

    if (count($result) == 0) {
        break;
    }

    $results = array_merge($results, $result);

    $currentPage++;
}