Pagination

The Lending Core uses three list shapes, chosen per resource family, and a loop written for the wrong one does not fail loudly — it stops early, or it never stops at all.

Operational lists end with a short page

Payments, fundings, statements, restrictions, reconciliation exceptions, and external parties accept limit (1–200, default 50) and offset, and return an items array:

curl "$BASE/v1/loans/7204/payments?status=POSTED&limit=50" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender"

{ "items": [{ "paymentId": 9011, "loanRef": "7204", "status": "POSTED", "amount": "517.14", "currency": "USD" }] }

Customer and form-entry lists additionally echo the paging inputs — { "limit": 50, "offset": 0, "items": [...] }. Values outside the documented range return a validation error rather than being clamped: a silent clamp hands back 200 rows to a caller who asked for 500, and looks exactly like a collection that has run out.

A cursor is a position, not a key

Customer history, address history, and portfolio search page with a cursor:

curl "$BASE/v1/customers/412/history?limit=50&cursor=cur_eyJzb3J0S2V5IjoiLi4uIn0" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender"

Send nextCursor unchanged on the next request. A cursor encodes a position under one endpoint’s ordering and may be signed or versioned, so one you decoded, edited, minted, or carried over from another endpoint names a place in an ordering that endpoint never produced — and a signed cursor will not verify at all. Repeat the same filters and caller context with the cursor: changing the query starts a new traversal, and the server can reject a cursor whose fingerprint does not match.

Only the native lists report a total

The native loan and journal-entry lists take offset and limit (the loan list adds orderBy and sortOrder) and return a counted list:

{
  "totalFilteredRecords": 1,
  "pageItems": [
    { "id": 7204, "accountNo": "000007204", "clientId": 412, "status": { "code": "loanStatusType.active" } }
  ]
}

Everywhere else, list responses omit totals by design: exact counts over filtered, permission-aware, changing datasets are expensive and stale before the next page. Use a named report when you need an auditable count.

A misspelled paging control fails loudly

A query parameter the endpoint does not document returns 400, catching borrowed paging controls before they quietly return the default page — a pageSize sent to a list that wants limit would otherwise return 50 rows, successfully, forever.

A live list is not a snapshot

Each list documents its ordering — customer lists are newest-modified first, payment and funding lists newest first. Offset pages can skip or repeat rows when records are inserted mid-traversal, and a resource state can change after its row was read. A live list is not a snapshot unless the endpoint says so.

Each page is authorized on its own

Authorization applies to each page: if the client’s visibility changes mid-traversal, later pages reflect current access. Hidden-record counts cannot be inferred from page sizes or cursors — the gap you would be measuring is the existence of records the caller was deliberately not shown.

Servicing pages the same way, with one exception

Implemented Servicing Workspace collections use limit (1–200, default 50), and offset or cursor only where the operation declares it. Most return:

{ "items": [], "limit": 50, "offset": 0, "hasMore": false }

Case effects are the current cursor exception: GET /v1/servicing/cases/{caseId}/effects accepts limit plus cursor and returns items, nextCursor, and hasMore. offset and cursor are never interchangeable.