Overview
List endpoints use page-based pagination with two query parameters:limit— number of items per page (default 50, min 1, max 100)page— 1-based page index (default 1)
data.items[] array and a data.meta object that reports the pagination state.
Request
Passlimit and page as query parameters on any list endpoint (e.g., chains, loans, withdrawals, corridors, utilizations).
Common query parameters
| Name | In | Type | Default | Min | Max | Notes |
|---|---|---|---|---|---|---|
| limit | query | integer | 50 | 1 | 100 | Items per page |
| page | query | integer | 1 | 1 | — | 1-based page number |
Some endpoints also accept additional filters (e.g.,status,chainId,loan_id,corridor_id). Filters combine with pagination.
Response Shape
All list responses follow the same structure:meta fields
limit— the page size used for this response.page— the current 1-based page number.total— total number of items that match the query (across all pages).
totalPages = ceil(total / limit).
Example
Best Practices
- Use stable sorting: if the endpoint supports sorting, keep it consistent between requests to avoid duplicates or gaps when data changes.
- Paginate deterministically: when filtering by mutable fields (like
status), expecttotaland page counts to change over time. - Handle bounds: if
pageis beyond the last page (page > ceil(total/limit)), you may receive an emptyitemsarray. - Validate inputs: invalid
limit/pagevalues return a validation error (400or422) with a structured error body. - Backoff & retry: if you hit rate limits (
429), retry with exponential backoff before continuing pagination.

