clock 2-minute read calender 2.4.0 | updated Apr. 24, 2024

It's a real page-turner

You can use pagination parameters to manage a response with large amounts of data. Adjusting these parameters can improve system performance. You can limit or parse data to prevent a lag or delay in a response. You can control how much information is returned in a response.

Pagination parameters are usually available on APIs that return lists of transactions like the ACH Inquiry API, Wire Inquiry API, Previous Day API, Intraday API, and RTP Send Payment API. There are several pagination parameters that can help you control how an endpoint will return the information requested.





ACH Inquiry POST /accounts/transactions/v1/returnACHtransactions/list
POST /accounts/transactions/v1/collectedACHtransactions/list
POST /accounts/transactions/v1/postedACHtransactions/list
POST /accounts/transactions/v1/ACHStatusInquiry/list


Wire Inquiry POST /wireInquiry/v1/transactions/details Optional


Previous Day POST /ddaReports/accounts/v1/transactions/list Optional


Intraday POST /ddaReports/accounts/v1/transactions/intraday/list Optional


RTP Send Payment GET /rtp/v1/payment/rtp/participant Required



Common pagination controls

Row pagination

There are common pagination parameters like startRowIndex and endRowIndex that help retrieve and organize large data sets into separate, scrollable pages. This is commonly used with information reporting and transaction inquiry APIs. These are optional fields and not required for the request.

  • The startRowIndex query string parameter sets the first row of data of the response. The default value is 1.
  • The endRowIndex query string parameter sets the final row of data of the response. The default value is 1000 records and is also the maximum number of records allowed in a single transaction.
  • If the startRowIndex or endRowIndex parameters are blank, all the rows of data return up to the maximum limit of the endRowIndex value for transaction records.
  • In the response header of the API, an endpoint may return totalRows or retrievedRows. These parameters provide a summary of the total number of transactions that match the request criteria or were retrieved based on the request criteria.



Here is an example of a request with general pagination parameters applied in the query string for the Previous Day API:

POST /ddaReports/accounts/v1/transactions/list?startRowIndex=1&endRowIndex=20

In this example, the startRowIndex is 5 so the first row of data is the fifth row, skipping the first four rows of data. The endRowIndex is 20 so that there is only 20 records per page following the fifth row.

Offset pagination

The offset pagination parameters are limit and offset. These parameters tell the server how many records to search for at a time and what records to skip. This parameter is not reliant on the sort controls and is not a recommended parameter for very large sets of data. Offset pagination is available with the RTP Send Payment API and is required for the RTP list of participants endpoint.

  • The limit is a query string parameter field that tells the server what items to return during a search. The limit restricts how many rows are returned. There is no maximum limit to this parameter.
  • The offset is a query string parameter field that specifies which set of rows to return. You can use this field to set the starting row for the data that is returned, and control what rows of data to skip. The default value is zero (0).
  • Be cautious when you use these parameters because if the data set changes it can affect the result and may return an incorrect response.



Here is an example of a request with the offset pagination parameters applied in the query string for the RTP Send Payment API:

GET /rtp/v1/payment/rtp/participant?limit=15&offset=0

In this example, the offset is 0 so that no items are skipped, and the limit is 15 meaning the request will search 15 items at a time.