Skip to main content

Filtering, sorting, and pagination

Collection endpoints such as GET /projects accept query parameters that the API applies before returning records. The API filters matching records, orders them, and then applies the requested offset and page size. Clients receive that page in the API's order.

These parameters apply to collection queries that expose field comparison filters in their endpoint reference. Individual-record lookups and simple lookup-list endpoints have different contracts. Use the parameters listed for the endpoint you are calling.

Filter by creation date​

Projects support these creation-date bounds:

  • createDate[gte] includes records created at or after the timestamp.
  • createDate[lt] includes records created before the timestamp, excluding the boundary.

Use ISO 8601 timestamps with an explicit timezone. For example, the UTC calendar year 2026 uses createDate[gte]=2026-01-01T00:00:00Z together with createDate[lt]=2027-01-01T00:00:00Z. Omit one bound for an open-ended range. Both bounds and any other supplied filters apply together.

For a business calendar in another timezone, convert its start and end to UTC or include the appropriate explicit offset. The timestamp returned by the API does not establish the original business timezone of the stored date.

Other filter names come from each endpoint's reference. A bare field name is an equality filter, such as projectId=8423. Comparison filters use bracketed operators, such as projectId[gt]=8000. A returned field is not automatically a supported query parameter; use the documented fields for that endpoint.

Sort on the server​

Use sort_by=asc(fieldName) or sort_by=desc(fieldName):

  • sort_by=asc(createDate) returns older matching projects first.
  • sort_by=desc(createDate) returns newer matching projects first.
  • sort_by=asc(projectId) orders projects by their ID.

Choose a scalar field supported by the collection query. Related objects and computed output-only fields are not general sort keys. If sort_by is omitted, the endpoint retains its default order.

Keep the same sort across pages. Records with equal values in the selected sort field have no guaranteed relative order. A unique ID provides an unambiguous ordering for exports. This guide describes a single sort field.

Request successive pages​

start is the zero-based number of matching, sorted records to skip. limit is the positive number of records to request for that page. For 100-record pages, request start=0, then start=100, then start=200, while keeping limit=100 and all filters and sorting unchanged.

Page-size limits and default behavior can differ by endpoint. This guide does not define an API-wide maximum. The Zapier integration's 100-record page cap is a separate integration setting.

To retrieve a complete set, continue until the endpoint returns an empty array. Keep each record's ID and reconcile IDs across pages. Offset pagination does not create a snapshot: records inserted, removed, or changed during the export can shift the contents of later pages.

Example: projects created in 2026, newest first​

curl --get 'https://emanageone.azure-api.net/emws/projects' \
  --header "x-api-key: $EMANAGE_API_KEY" \
  --data-urlencode 'createDate[gte]=2026-01-01T00:00:00Z' \
  --data-urlencode 'createDate[lt]=2027-01-01T00:00:00Z' \
  --data-urlencode 'sort_by=desc(createDate)' \
  --data-urlencode 'start=0' \
  --data-urlencode 'limit=100'

The response is a JSON array of the first requested page of matching projects. For the next page, change only start to 100. URL-encode query parameter names and values as the example does, including the brackets and parentheses.

The project response includes projectId and createDate. For a spreadsheet export, retain projectId in its own column so each project can be reconciled with its existing row.