Filtering & sorting · LendEasy Docs

Use each resource's closed, documented filter set, half-open time windows, and documented ordering without turning list endpoints into an ad hoc query language.

Each list endpoint exposes a closed, documented filter set. An unknown parameter — filter, sort, or paging — returns 400; it is never silently ignored. There is no generic query language across resources.

Per-resource filter sets

Three representative examples:

Endpoint	Documented filters
`GET /v1/loans/{loanId}/payments`	`status` (repeatable), `source`, `rail`, plus `limit`/`offset`.
`GET /v1/loans`	`externalId`, `accountNo`, `clientId`, `status`, plus `offset`/`limit`/`orderBy`/`sortOrder`.
`GET /v1/external-parties`	`partyType`, `verificationState`, `active`, and `search` — a case-insensitive substring match on display name.

Filter values are the documented enums and identifiers, not free text:

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

An ID filter remains tenant-scoped and permission-aware. A valid ID outside the caller’s visibility does not become a cross-tenant probe.

Time windows

The endpoint declares which time field a filter uses and its boundary rule. Customer history takes a half-open instant window — occurredFrom inclusive, occurredTo exclusive:

occurredFrom = 2026-09-01T00:00:00-07:00   (inclusive)
occurredTo   = 2026-10-01T00:00:00-07:00   (exclusive)

Half-open windows compose without double-counting a boundary event. Journal entries instead take inclusive fromDate/toDate business dates. Send RFC 3339 offsets for instants and ISO YYYY-MM-DD for business dates, and read each endpoint’s boundary semantics rather than assuming one convention.

Ordering

Most Lending Core lists have a fixed documented order — customers newest-modified first, payments and fundings newest first. Only the native loan and journal-entry lists accept orderBy and sortOrder (ASC/DESC). There is no generic sort parameter.

Multiple values

Where documented, repeat a parameter rather than inventing comma syntax:

status=POSTED&status=SETTLED_PENDING_POST

Repeated values are OR within the same field; filters across different fields are AND.

Search is different

GET /v1/portfolio/search?q=... is the permission-aware discovery endpoint for customers and loans: name token-prefix, exact current email, canonical phone, and exact loan account number. Filtering is exact selection inside one resource collection. Neither supports raw restricted identifiers, account credentials, note text beyond caller sensitivity, or arbitrary database predicates — exact-identifier lookup has its own audited route, POST /v1/customers/lookup.

Persist the IDs from create and search responses. Building filters from display names produces ambiguity and can expose more personal information in URLs and logs than necessary.