Pagination & list conventions

This API does not use a single global pagination envelope. List endpoints fall into one of three shapes, described below. Each endpoint's own doc states which shape it uses and which filters it accepts; unknown query parameters are ignored.

1. Page-based (admin lists)

Most GET /admin/* list endpoints use classic page pagination.

Query parameters

Parameter	Type	Description
`limit`	integer (1–100)	Items per page. Default varies by endpoint (commonly `25`).
`page`	integer (≥1)	Page number. Default `1`.

Response

{
  "items": [ /* ... */ ],
  "meta": {
    "total": 137,
    "per_page": 25,
    "current_page": 1,
    "last_page": 6
  }
}

2. Cursor-based (order history)

High-volume history endpoints (e.g. GET /orders, GET /driver/orders) use cursor pagination.

Query parameters

Parameter	Type	Description
`limit`	integer (1–100)	Items per page. Default `25`.
`cursor`	string	Opaque cursor from the previous response's `next_cursor`.
`status`	string	Optional status filter (see order statuses).
`date_from`	date	Filter `created_at >=`.
`date_to`	date	Filter `created_at <=` (must be `>= date_from`).

Response

{
  "items": [ /* ... */ ],
  "next_cursor": "eyJpZCI6MTIzfQ",
  "has_more": true
}

Pass next_cursor back as ?cursor= to fetch the next page. When has_more is false, next_cursor is null.

3. Flat list (capped)

A few convenience endpoints (e.g. GET /orders/history) return a plain array under a named key, capped by limit.

Query parameters

Parameter	Type	Description
`limit`	integer (1–100)	Max items returned. Default `20`.

Response

{ "orders": [ /* ... */ ] }