Pagination

The Pointeron V2 API uses cursor-based pagination. This guide explains its parameters, response format, and how to iterate through complete result sets. V1 page-number pagination has a separate contract described below.

How it works

Every list endpoint returns results in pages. The response includes a meta object that tells you whether more results exist and provides the cursor to fetch the next page. Cursors are opaque strings -- do not attempt to construct or modify them.

Request parameters

curl -G https://api.pointeron.com/v2/assets \
  -H "Authorization: Bearer ${POINTERON_ACCESS_TOKEN}" \
  -d limit=10

Response format

{
  "object": "list",
  "data": [
    {
      "id": "ast_WAz8eIbvDR60rouK",
      "name": "Delivery Van 01",
      "type": "vehicle"
      // ...
    },
    {
      "id": "ast_hSIhXBhNe8X1d8Et",
      "name": "Fleet Truck 05",
      "type": "vehicle"
      // ...
    }
  ],
  "meta": {
    "has_more": true,
    "next_cursor": "eyJpZCI6ImFzdF9oU0loWEJoTmU4WDFkOEV0In0"
  }
}

Fetching the next page

To get the next page of results, pass the next_cursor value from the previous response as the cursor parameter.

curl -G https://api.pointeron.com/v2/assets \
  -H "Authorization: Bearer ${POINTERON_ACCESS_TOKEN}" \
  -d limit=10 \
  -d cursor="eyJpZCI6ImFzdF9oU0loWEJoTmU4WDFkOEV0In0"

Paginating through all results

Here is a complete example that fetches every asset in your organization by following cursors until has_more is false.

async function getAllAssets(apiKey) {
  const baseUrl = 'https://api.pointeron.com/v2/assets'
  const allAssets = []
  let cursor = null

  do {
    const params = new URLSearchParams({ limit: '100' })
    if (cursor) params.set('cursor', cursor)

    const response = await fetch(`${baseUrl}?${params}`, {
      headers: { Authorization: `Bearer ${apiKey}` },
    })

    const json = await response.json()
    allAssets.push(...json.data)
    cursor = json.meta.next_cursor
  } while (cursor)

  return allAssets
}

V1 page-number pagination

V1 list endpoints use page and per_page rather than V2 cursors. Existing V1 response shapes remain supported. The canonical V1 pagination foundation does not change any endpoint by itself: only endpoints whose documentation explicitly advertises support may opt in with X-Pointeron-Pagination: canonical-v1.

On a participating endpoint, omitting the header preserves the legacy response. The canonical response requires top-level success (always true), message, request_id, a data array, pagination links, and pagination meta. Endpoint-specific extras such as stats and summary remain typed top-level fields. Both representations include X-Pointeron-Pagination in Vary. An unsupported selector, including an empty header, returns HTTP 406.

Supported GET lists include users, assets, categories and geofences, plus their organization-scoped variants; iCloud and GPS accounts and devices; both device pools; available iCloud replacement devices; and organization iCloud devices. Category trees retain their complete, unpaginated response. The operation's OpenAPI definition documents its exact resource, extras and limit profile.

The standard canonical page size is 15, with a maximum of 100. The documented profiles for GPS and iCloud pools (50, maximum 500), assets (25, maximum 5000), and geofences (15, maximum 5000) are exceptions. Invalid canonical pagination parameters return HTTP 422. These profiles do not retroactively change existing endpoints.

Clients must check each endpoint's contract before sending the header and must continue through subsequent pages when they need a complete list. Updated clients must handle both representations during rollout. Legacy support remains for at least six months after an announced deprecation, and longer while supported installed mobile builds or external integrations depend on it.