Polling for Changes with Timestamp Filters

Set the updatedAt[gte] query parameter to the timestamp of your last successful sync to retrieve records modified since then. You can use updatedAt[gte] with GET /v1/workorders, GET /v1/parts, GET /v1/assets, and GET /v1/purchaseorders.

Basic Pattern

1. On each polling cycle, request records with updatedAt[gte]=<lastSync>.
2. Carry the same filter across every page so you don't miss records updated while you paginate.
3. After consuming all pages, advance your next sync watermark to the maximum updatedAt value observed in the response.
4. Deduplicate by id: a record returned in multiple windows should be processed only once.

Example

Request work orders updated on or after 2026-10-20T18:35:34.139Z:

GET /v1/workorders?updatedAt[gte]=2026-10-20T18:35:34.139Z
Authorization: Bearer {token}

Example response:

{
  "workOrders": [
    {
      "id": 186528000,
      "sequentialId": 56,
      "assetId": null,
      "createdAt": "2026-10-22T13:19:49.521Z",
      "creatorId": 11112,
      "customerId": null,
      "description": "Replace the HVAC filter",
      "externalId": null,
      "locationId": null,
      "organizationId": 12345,
      "partStatus": "NO_PARTS",
      "priority": "NONE",
      "status": "OPEN",
      "title": "HVAC Maintenance Required",
      "type": "REACTIVE",
      "updatedAt": "2026-10-22T13:19:49.521Z",
      "workOrderSummary": null
    }
  ],
  "nextCursor": null,
  "nextPageUrl": null
}

Pagination

Work orders use cursor pagination. Parts, assets, and purchase orders currently use offset pagination. With offset pagination, records updated while you page through a result set can move between pages, so clients should deduplicate by id and use a small overlap window.