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.