Pagination

How list endpoints work today

List endpoints take a limit query parameter (clamped server-side, typically to a maximum of 500) and return up to that many results in one response โ€” the most recently created first.

curl "https://api.kwiikpay.io/api/v1/partner/customers?limit=100" -H "X-Api-Key: kwp_live_..."
{
  "success": true,
  "status_code": 200,
  "message": "Customers retrieved successfully.",
  "data": {
    "customers": [ { "...": "..." } ],
    "pagination": { "current_page": 1, "last_page": 1, "per_page": 100, "total": 3 }
  }
}

A known current limitation

There is currently no way to page past the first limit results on /api/v1/partner list endpoints โ€” there's no offset, cursor, or "next page" parameter. If you have more records than your limit, filter more narrowly (by status, date range, or another supported filter) rather than relying on pagination to enumerate everything. A real cursor-based pagination scheme (with an honest has_more signal) is planned for the next API generation; this guide will be updated when it ships.

/api/v2/public list endpoints behave the same way today: limit bounds the response, and there is no continuation mechanism yet.

In practice

For most integrations this isn't a problem โ€” you're usually listing a bounded, filtered set (one customer's fiat accounts, one subscription's recent delivery attempts) well under the limit. It matters if you're trying to enumerate your entire customer base through the API; for that, prefer reacting to webhooks to keep your own store in sync incrementally, rather than re-listing everything.