Area: Payments / core list endpoints · Type: bug/enhancement (consistency, DX)
The API paginates list endpoints three different ways:
| Endpoint |
List at |
Pagination fields |
Where |
/v1/payments/transfers |
data[] |
total, page, pageSize, hasMore |
meta |
/v1/payments/transfer-batches |
data[] |
total, page, pageSize, hasMore |
meta |
/v1/counterparties |
data.counterparties |
total, page, pageSize (no hasMore) |
data |
/v1/wallets |
data.wallets |
none |
— |
Pagination is functional everywhere (pageSize limits results), but a caller can't reuse one pager, and /wallets gives no way to know the total or whether there's a next page.
Impact: every list endpoint needs bespoke pagination handling; /wallets can't be paged reliably from the response alone.
Suggested fix: standardize on { data:[...], meta:{ total, page, pageSize, hasMore, requestId } } (transfers/batches already use it); bring counterparties + wallets onto it and add total/hasMore to /wallets. (Error envelope is already uniform, this is pagination-only.)
Area: Payments / core list endpoints · Type: bug/enhancement (consistency, DX)
The API paginates list endpoints three different ways:
/v1/payments/transfersdata[]meta/v1/payments/transfer-batchesdata[]meta/v1/counterpartiesdata.counterpartiesdata/v1/walletsdata.walletsPagination is functional everywhere (
pageSizelimits results), but a caller can't reuse one pager, and/walletsgives no way to know the total or whether there's a next page.Impact: every list endpoint needs bespoke pagination handling;
/walletscan't be paged reliably from the response alone.Suggested fix: standardize on
{ data:[...], meta:{ total, page, pageSize, hasMore, requestId } }(transfers/batches already use it); bring counterparties + wallets onto it and addtotal/hasMoreto/wallets. (Error envelope is already uniform, this is pagination-only.)