Skip to main content
Midaz list endpoints deliver data in smaller, manageable portions. This improves response times and client-side processing, particularly for applications that load results incrementally. Other Lerian APIs set their own pagination parameters, defaults, and limits. Check each API’s reference.

Page-based pagination


Instead of returning the entire dataset in a single response, which can strain resources, clients can request specific subsets of data. Page-based endpoints accept two query parameters:
  • page (integer): Specifies the page number to retrieve. The default value is 1.
    • Values below 1 return an error.
  • limit (integer): Defines the maximum number of items per page. The default value is 10.
For example, to retrieve the first page of organizations with a maximum of 10 items per page:

Pagination response

The pagination response includes the following structure:
  • items: An array of entities retrieved for the current page. Each object contains detailed information about the resource requested, as shown in the example below.
  • page: The current page number, starting from 1 (default).
  • limit: The maximum number of items included in the response, as defined in the request or default configuration.
Below is an example response for a paginated request:

Maximum page size

By default, Midaz accepts a maximum of 100 items per page (limit=100). This restriction avoids excessive payload sizes. If your use case requires retrieving a larger number of items per request, you can override this limit by setting the MAX_PAGINATION_LIMIT environment variable in your deployment configuration ( .env file). Billing package lists keep the 100 maximum.
Increasing the pagination limit may result in slower response times depending on the volume of data and infrastructure conditions. Be sure to test thoroughly in staging environments before applying the change in production.
After you change it, restart the Ledger. To set it on a Midaz deployment, see the Midaz chart README.

Cursor-based pagination


Some endpoints use cursor-based pagination instead of page numbers. This approach is more efficient for large or frequently changing datasets. Cursor-based endpoints accept the following query parameters:
  • cursor (string): An encoded token from a previous response (next_cursor or prev_cursor) to navigate forward or backward. Omit this parameter to start from the beginning.
  • limit (integer): The maximum number of items per page.
  • sort_order (string): The direction used to sort results. Accepted values: asc (ascending) or desc (descending).
Set sort_order on the initial request and keep it unchanged while you follow the cursors.
For example, to retrieve balances using cursor pagination:

Cursor pagination response

The response includes the following structure:
  • items: An array of entities for the current page.
  • next_cursor: An encoded token to retrieve the next page. If absent or empty, there are no more results.
  • prev_cursor: An encoded token to retrieve the previous page. If absent or empty, you are on the first page.
  • limit: The maximum number of items included in the response.
To navigate to the next page, pass the next_cursor value as the cursor query parameter:
Below is an example response for a cursor-paginated request:

Which endpoints use cursor pagination?

Each endpoint’s API reference shows whether it takes page or cursor.