Pagination cursors are becoming self-contained

We're changing how pagination cursors are generated across the Samsara API. Today, cursors reference pagination state stored on Samsara's side; going forward, they will carry that state within the token itself.

Pagination behavior is unchanged. Continue reading endCursor from each response and passing it back in the after parameter. Cursors remain opaque tokens and should be passed back exactly as received — never parsed, validated, or truncated.

What's changing: cursors will be longer — in some cases significantly longer than before. Two things to check in your integration:

• Storage. If you persist cursors anywhere, even temporarily, make sure the location isn't length-limited. A fixed-length SQL column such as CHAR(36) or a bounded VARCHAR can truncate or reject a longer cursor and break pagination. Use an unbounded or large text type (for example, TEXT), a file, or other storage without a fixed-length cap.
• URL length. If you send multiple after cursors in a single request URL, longer cursors may push you over URL length limits and result in 414 errors. Send one cursor per request.

As a practical bound, cursors can reach roughly 16 KB, though in practice they are much smaller; when pagination state would exceed what fits in the token, the API automatically falls back to a compact reference instead.

This change will begin rolling out gradually on August 6, 2026 with a small set of organizations. If you have a flow that can't be updated in time, contact [email protected] and we can defer the rollout for that flow.