Continue from a cursor
When a response contains nextCursor, send that value unchanged as cursor on
the next request. Keep the site, hierarchy and tag filters, time range,
aggregation interval, and page size unchanged. Do not decode, edit, construct,
or reuse a cursor with another query.
GET /api/customer/v1/data?siteId=site-1&lineId=line-1&from=2026-09-01T12%3A00%3A00Z&to=2026-09-01T13%3A00%3A00Z&aggregationIntervalSeconds=60&pageSize=1000&cursor=<nextCursor>
Authorization: Bearer <access-token>
Continue until nextCursor is null. Each page is a separate request and counts
toward the daily request allowance.
Distinguish continuation from a snapshot
A cursor records where to continue the requested ordering. It does not freeze the result set or cache a snapshot of every value.
Data can arrive late or be corrected after an earlier response. A later request
for the same range can therefore return different value, minimum, maximum,
or sampleCount values, and an interval that was empty can later contain data.
Changes near a page boundary can also repeat or omit a point while following an
older cursor.
Treat aggregates as revisionable rather than append-only. This is an observable consistency contract, independent of how the service stores or recalculates the data.
Reconcile a settled interval
When final historical values matter, wait until the interval is expected to be complete and request the entire interval again without an earlier cursor. Follow the new cursor chain to completion, then upsert each point by logical series identity and bucket timestamp.
Choose a lateness window appropriate for your process. Repeat reconciliation after that window closes when exact historical reporting matters.
Merge aggregate pages
A logical aggregate series is identified by siteId, lineId, machineId,
deviceId, and tagGuid. The same series can appear on several pages. Merge
its points by that identity and points[].timestamp; do not treat each series
envelope as a separate signal.