Choosing between offset and cursor pagination for Confluence content search

Goal

To reliably iterate over thousands of Confluence pages via the REST API while minimizing duplicated or missing items caused by concurrent content changes.

Constraints

• Confluence Cloud v2 uses cursor‑based pagination; Data Center and legacy v1 endpoints use numeric offsets.
• Offset pagination can skip or duplicate items if pages are added or removed between requests; total size is not always returned.
• Cursor tokens are opaque but may change if the index is rebuilt; the API does not expose the underlying query state.
• Bounding the query with a tight CQL filter (e.g., space, last‑modified range) reduces the result set but does not eliminate race conditions.

Unresolved Decision

Should a client rely on offset pagination with a tightly bounded CQL search, or migrate to the cursor‑based v2 endpoints, given the differing behavior between Cloud and Data Center deployments?

Specific Questions

1. Which pagination strategy provides a more stable traversal of a mutable content set in Confluence Cloud versus Data Center?
2. How can a client mitigate duplicate or missing items when using offset pagination in a rapidly changing environment?
3. Does the v2 cursor‑based API guarantee idempotent paging across content changes, or are there edge cases that still require additional filtering?