Pagination

The platform standard is cursor-based (keyset) pagination: limit + cursor.

Request

curl "https://api-gateway.lunixi.com/api/v1/wallet/operations?limit=25" \
  -H "Authorization: Bearer $LUNIXI_TOKEN"

Response

pageInfo always sits next to data — not inside it.

{
  "status": "success",
  "code": "SUCCESS",
  "data": [ { "id": "wop_01J8ZU..." } ],
  "pageInfo": {
    "hasMore": true,
    "nextCursor": "eyJ2IjoxLCJ0IjoiMjAyNi0wOC0xN1QxMDowMDowMC4xMjM0NTZaIiwiaWQiOiJ3b3BfMDFKOFpVIn0",
    "totalCount": null
  },
  "requestId": "req_01J8ZV..."
}

On an endpoint whose data is an object the same response looks like this — pageInfo is still in the same place:

{
  "status": "success",
  "code": "SUCCESS",
  "data": { "items": [ { "id": "sub_01J8ZU..." } ] },
  "pageInfo": { "hasMore": false, "nextCursor": null, "totalCount": null },
  "requestId": "req_01J8ZV..."
}

What you need to know

• totalCount is null by default. A total is expensive under cursor pagination (a filtered COUNT(*) is a full scan). Use hasMore to advance. If you genuinely need the number, send includeTotal=true — that request is slower and counts more heavily against your rate limit.
• Pagination is forward-only. There is no prevCursor. To navigate backwards, keep the cursors you have seen on your side.
• The cursor is opaque. Do not decode it, construct it, or edit it — the format can change without notice. Send back only the value you received in the previous response.
• Ordering is always newest-first and deterministic. Even if the list keeps being written to while you page through it, no record is repeated or skipped.
• Reset the cursor if you change filters (start from the beginning). A cursor is bound to the query that produced it.

INVALID_CURSOR

A malformed, unrecognised or unsupported-version cursor returns 400 INVALID_CURSOR.

{
  "status": "failure",
  "code": "INVALID_CURSOR",
  "statusCode": 400,
  "message": "Invalid pagination cursor — …"
}

What to do: do not construct cursors yourself; send back the pageInfo.nextCursor value from the previous response verbatim. If you changed filters, reset the cursor.

Walking every page

let cursor: string | undefined;
 
do {
  const qs = new URLSearchParams({ limit: '100', ...(cursor ? { cursor } : {}) });
  const res = await fetch(
    `https://api-gateway.lunixi.com/api/v1/wallet/operations?${qs}`,
    { headers: { Authorization: `Bearer ${process.env.LUNIXI_SECRET_KEY}` } },
  );
  const body = await res.json();
 
  // On this endpoint `data` is an object; on others it may be an array.
  // `pageInfo` is in the same place either way — next to `data`.
  process(body.data.operations ?? body.data.items ?? body.data);
 
  cursor = body.pageInfo.hasMore ? body.pageInfo.nextCursor : undefined;
} while (cursor);

Legacy parameters

Some endpoints still accept the historical page, offset, pageSize, pageToken, beforeSeq and cursorCreatedAt+cursorId parameters. They keep working, but using them makes the response carry:

Deprecation: true
Sunset: Sun, 31 Jan 2027 00:00:00 GMT
X-Deprecated-Params: offset

Endpoint status

The migration is in progress. Where things stand today:

Endpoints that accept a cursor

Not paginated yet — here limit is not a page size but a cap: records beyond it are not reachable today, and the response does not say so. Think of it as "returns the newest N records".

Not paginated by design — do not wait for a cursor on these; none is coming:

Panel / operator surface — these require an RBAC permission and are not listed in Swagger; they belong to the panel, not to an integration flow.

Related

• Error Handling — the envelope and the codes
• API Overview — base URL and request format