Page through lists
How to read a long list of orders and not lose records.
List endpoints use limit and offset. They return hasMore.
| Parameter | Default | Maximum |
|---|---|---|
limit | 50 | 200 |
offset | 0 | — |
{ "data": [], "hasMore": true, "limit": 50, "offset": 0 }Send both update times
To filter GET /v1/orders by update time, send updatedSince and updatedUntil.
If you send only one, the API returns 422
invalid_time_range.
Why. An open window grows while you read it. If an order changes, it moves to the top of the list. You read that position already, so you never see the order. The API rejects an open window to prevent this.
Read a long period
Read one window to the end. Then move updatedSince to the old updatedUntil. Repeat.
window 1: [08:00, 09:00)
window 2: [09:00, 10:00)
window 3: [10:00, 11:00)updatedSince is inclusive and updatedUntil is exclusive. The windows touch. There is no
gap and no overlap.
Set updatedUntil a few minutes in the past. Orders in an old window do not usually change
again.
You can send no time filter. Use this for the first call.
Pickup and delivery filters are different
pickupFrom, pickupUntil, deliveryFrom and deliveryUntil have no pair rule. You can
send one alone.
These filters read the planned times. A planned time does not move, so the list stays stable while you read it.
These filters do not replace the update window. A status change does not change
pickupTime. To find what changed, use updatedSince and updatedUntil.
Read one morning
GET /v1/orders?pickupFrom=2026-08-12T08:00:00%2B02:00
&pickupUntil=2026-08-12T12:00:00%2B02:00
&sort=pickupTimeThis gives the collections for that morning, in time order.