Pagination

Two list endpoints, and both paginate the same way: an opaque cursor. Same query params, same response shape, same loop — so one shared helper covers both.

Endpoint	Query params	Default limit
GET /orders	cursor, limit	20
GET /me/wallets/{currency}/transactions/{type}	cursor, limit	10

limit caps at 100 on both.

The loop

Omit cursor on the first call:

GET /orders?limit=20

{
  "data": [ { "id": "0190f9b2-...", "status": "PENDING" } ],
  "pagination": {
    "next_cursor": "eyJjcmVhdGVkQXQiOiIyMDI2LTA4...",
    "has_more": true,
    "limit": 20,
    "total": 359
  }
}

Then pass the previous next_cursor back in until has_more is false. When there is nothing left, next_cursor is null.

GET /orders?limit=20&cursor=eyJpZCI6IjAxOTBmO...

Wallet transactions take exactly the same shape:

GET /me/wallets/USDR/transactions/top_up?limit=10
GET /me/wallets/USDR/transactions/top_up?cursor=eyJpZCI6IjAxOTBmO...

Four rules the cursor imposes

Treat it as opaque. Do not parse it, build it, or persist it as a long-lived bookmark. Its contents are internal and can change without notice. A malformed or tampered cursor answers 400.

An empty ?cursor= is not "start over." It is an invalid cursor, and it answers 400. To get the first page, leave the parameter out entirely.

limit is fixed by the first call. While you are passing a cursor, changing limit mid-walk would skip or duplicate rows, so it is ignored. Decide your page size before you start.

You can only move forward. There is no index to jump to — only the next cursor. To offer a "back", keep the cursors you have already walked. total gives you the "of N" when it is present, but it is nullable, so do not build a UI that falls apart without it.

Filters

GET /orders also takes status, type, idempotency_key, created_from and created_to (dates as 2026-07-01). status accepts a comma-separated list; type (transaction type, e.g. WALLET_TO_POG) takes a single value only. Keep the filters identical across every call in a paging loop — changing them mid-loop invalidates the cursor's assumptions, and idempotency_key is precise enough to make paging moot anyway (see idempotency).

Signing

Both endpoints require a signed request, in query mode — and the cursor counts as part of the query string you sign, so build the message from the URL you are about to send, not from the one you sent last page.