Skip to content

Filtering and sorting

List endpoints share a small set of query conventions. The API reference is authoritative per endpoint — this page is what holds across them.

GET /api/expenses?page=2&pageSize=50
Parameter Default Range
page 1 ≥ 1
pageSize 20 1–100

Paginated endpoints return the page alongside its totals, so you can size the pager without walking the collection:

{
"expenses": [],
"page": 2,
"pageSize": 50,
"total": 412,
"totalPages": 9
}

Not every list is paginated. Bounded collections — the notes on one entity, the units of one property, and some portfolio lists such as GET /api/properties — return the whole set with no page fields at all. If the response carries no total, the endpoint does not paginate and page / pageSize are ignored.

Where sorting is supported it is two parameters, and sortBy is a fixed enum rather than an arbitrary field name:

GET /api/vendors?sortBy=name&sortDirection=asc
GET /api/work-orders?sortBy=priority&sortDirection=desc

sortDirection is asc or desc. The allowed sortBy values differ per endpoint and are listed on its reference page.

Calendar dates are YYYY-MM-DD. Range filters come in *After / *Before pairs and are inclusive:

GET /api/vendors?createdAfter=2026-01-01&createdBefore=2026-03-31

Reporting endpoints instead take an explicit startDate and endDate.

Filters are exact-match on an id or an enum, and combine with AND:

GET /api/work-orders?status=open&priority=emergency&propertyId=9c4e…

Free-text search, where an endpoint supports it, is a separate search parameter. For search that spans resource types, use GET /api/search rather than filtering each list.