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. Endpoints with Pagination PAGINATION PARAMETER API ENDPOINT REQUIRED OR OPTIONAL startRowIndex endRowIndex 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 Optional startRowIndex endRowIndex Wire Inquiry POST /wireInquiry/v1/transactions/details Optional startRowIndex endRowIndex Previous Day POST /ddaReports/accounts/v1/transactions/list Optional startRowIndex endRowIndex Intraday POST /ddaReports/accounts/v1/transactions/intraday/list Optional limit offset 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. Example 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. Example 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.