Pagination

List endpoints in MidasPay (fund-split detail lists, merchant quotes, profit-sharing, etc.) can return very large result sets. All list endpoints use offset-style pagination with the same field conventions.

Request parameters

Field	Type	Constraints	Description
`page_number`	int32	`≥ 1`	1-based page index.
`page_size`	int32	`≥ 1`, endpoint-specific maximum	Records per page.

The maximum page_size varies by endpoint:

Endpoint family	Max `page_size`
Fund-split detail list (`/v1/fund_split/get_detail_list`)	`100`
Profit-sharing detail list	`100`
Merchant-quote query (`/v1/merchant_quote/get_quotation_info`)	`5000`

Both fields are required on list endpoints that support pagination — there is no implicit default. Always send a concrete value.

Response envelope

Every paginated response carries the same header fields plus an endpoint-specific array of records. The array's field name is endpoint-specific (e.g. order_detail, quote_info) — there is no generic items field.

{
  "total":        1234,
  "total_pages":  13,
  "page_number":  3,
  "order_detail": [ /* up to page_size records */ ]
}

Field	Description
`total`	Total number of records matching the filter across all pages.
`total_pages`	Total number of pages at the current `page_size`.
`page_number`	Echo of the page you fetched.
(endpoint-specific array)	The page of records — name varies by endpoint. Inspect the endpoint's reference page for the exact field name.

Example — iterate every page

func iterateFundSplitDetails(req *FundSplitReq) error {
    req.PageSize = 100
    req.PageNumber = 1
    for {
        resp, err := client.GetFundSplitDetailList(ctx, req)
        if err != nil { return err }
        if len(resp.OrderDetail) == 0 { break }

        process(resp.OrderDetail)

        if req.PageNumber >= resp.TotalPages { break }
        req.PageNumber++
    }
    return nil
}

Offset pagination caveats

Skipped / duplicated rows: if a record is inserted or deleted between your page fetches, a row may appear twice or not at all.
Deep paging is slow: the database must scan + skip page × size rows. For large histories, narrow the query with date filters (see below) before paging.
Don't cache total_pages: the underlying result set can grow between requests.

Date filters on reconciliation endpoints

Fund-split and profit-sharing list endpoints accept transaction_begin_date and transaction_end_date filters. These filters use month granularity (YYYY-MM), not full dates:

POST /v1/fund_split/get_detail_list
{
  "transaction_begin_date": "2026-01",
  "transaction_end_date":   "2026-03",
  "page_number": 1,
  "page_size":   100
}

Month-granular, not day-granular

The date filter pattern is ^(\d{4})-(\d{2})$. Supplying a full date like 2026-01-15 will fail validation. If you need finer filtering, pull the month and filter client-side after the fetch, or use a different endpoint where available.

Scan patterns for archival jobs

For reconciliation jobs that pull all records in a range:

Bound the scan by month using transaction_begin_date / transaction_end_date — a single month at a time keeps total manageable.
Parallelise across months, not across pages of the same month — the offset-style paging is cheapest when the result set is small.
Deduplicate downstream on the natural primary key (e.g. the fund-split order ID) to defend against inserts happening mid-scan.

# Good: one month per job, full set of pages per month
for month in 2026-01 2026-02 2026-03 2026-04; do
  fetch_all_pages_of "$month"
done

# Bad: unbounded range forces a huge offset to reach the last pages
fetch_pages 1..62   # for a year's worth of data

Sort order

Each list endpoint has a stable default sort defined server-side. The exact ordering is documented on each endpoint's reference page; in all cases the sort is deterministic (ties broken by a unique secondary key), so repeated calls for the same page return the same records as long as the underlying data hasn't changed.

Cursor pagination

Cursor-based pagination is not available on general MidasPay list endpoints today. A small number of specialised endpoints (such as payout beneficiary lookups) accept an opaque cursor parameter — see their reference pages for details. All other list endpoints use page_number / page_size as described above.

Request parameters​

Response envelope​

Example — iterate every page​

Date filters on reconciliation endpoints​

Scan patterns for archival jobs​

Sort order​

Cursor pagination​

See also​