Which Confluence REST API pagination strategy best avoids duplicates in large datasets?
0 reputation · 01 Jul 2020, 05:18 UTC
0 reputation · 01 Jul 2020, 05:18 UTC
When pulling a full list of pages from Confluence via the REST API, the endpoint caps each request to 1,000 results and requires an offset via the start parameter. The goal is to enumerate every page reliably, even when the dataset exceeds the hard limit.
Because the API is offset‑based, inserting or deleting pages between paginated calls can cause the same item to appear on two pages or for an item to be skipped entirely. The lack of a cursor or token means there is no stable bookmark to resume from, and the documentation does not clarify whether the internal limit is enforced uniformly across all endpoints or only for external calls.
Given these constraints, which approach should developers adopt to guarantee a stable full‑dataset retrieval? Does the API guarantee that items returned in page N + 1 are disjoint from page N when content changes between requests? Is there a recommended workaround to avoid duplicates when using offset pagination in Confluence Cloud versus Server?
35275 reputation · 01 Jul 2020, 16:06 UTC
To guarantee a stable full-dataset retrieval in the Confluence REST API, you must implement client-side deduplication using a Set or Hash Map of unique identifiers (e.g., pageId). Because the API uses offset-based pagination (the start parameter) and lacks cursor-based bookmarks, it cannot guarantee that items in page N + 1 are disjoint from page N if the underlying data changes during the request sequence.
The API does not provide a snapshot of the dataset at the start of the pagination process. It performs a fresh query for every request. If a page is deleted or added at an index lower than your current start value, the entire index shifts:
while loop to increment the start parameter by the limit value (e.g., 0, 1000, 2000) until the API returns an empty list or the next link is absent.start values can increase server latency. If you encounter timeouts, reduce the limit (e.g., to 250) to lower the per-request load.You can verify the behavior of the offset by running two sequential calls and comparing the last item of the first set with the first item of the second set:
# Request 1
curl "https://your-domain.atlassian.net/wiki/rest/api/content?start=0&limit=50"
# Request 2
curl "https://your-domain.atlassian.net/wiki/rest/api/content?start=50&limit=50"
In Confluence Cloud, the API is strictly managed by Atlassian's infrastructure, and the 1,000-result cap is a hard limit. In Confluence Server/Data Center, the maximum limit may be configurable via system properties in server.xml or the admin console, but the fundamental risk of offset-shifting remains identical.
Missing Diagnostic: Are you performing these retrievals during a known maintenance window or during peak user activity? If the dataset is highly volatile, client-side deduplication is the only viable path; if it is static, a simple sequential loop is sufficient.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 01 Jul 2020, 06:50 UTC
Client-side deduplication catches duplicates, but it cannot recover records skipped when deletions shift the offset window. A more robust approach combines deduplication with a stable sort key—ordering by id or created narrows the window where concurrent writes cause drift. For guaranteed full-dataset consistency, native space export or backup tools remain preferable because they snapshot content without offset instability. For incremental syncs, CQL filters on lastModified can reduce crawl scope, though they do not replace a transactional snapshot. Because exact limit caps and any newer pagination semantics vary by Confluence version and deployment, verify the specific REST contract for your instance before relying on a fixed page size.