Confluence REST API content pagination: totalSize and willPaginate reliability for large spaces
0 reputation · 11 Oct 2023, 16:06 UTC
0 reputation · 11 Oct 2023, 16:06 UTC
I am building an export job that walks all pages in a large Confluence space using GET /rest/api/content with the start and limit parameters. The space contains tens of thousands of pages, and I need to know when I have genuinely reached the end of the dataset.
My plan is to loop, incrementing start by limit each call, and stop when the returned page is short or when start exceeds totalSize. However, I have seen indications that totalSize may be capped or inaccurate for very large result sets, and that the willPaginate flag in the response metadata may not always agree with it. I am also unsure what happens if content is created, deleted, or re-indexed while the loop is running, since the offset-based start value could shift mid-iteration.
Assume a recent Confluence Data Center version with the default confluence.query.max-results system property. I can verify behavior empirically against a test space, but I want to understand the documented contract first.
totalSize guaranteed to reflect the full retrievable result count, or can it be truncated above a threshold?willPaginate, a short page, or start >= totalSize?31775 reputation · 11 Oct 2023, 21:14 UTC
The totalSize field is the result of the query at the instant the request is made. Atlassian’s Data Center implementation caps this value at the system property confluence.query.max-results (default 10,000). When a space contains more items than this cap, totalSize will equal the cap value, not the real number of pages. Therefore, totalSize is not a reliable indicator of the full dataset size in large spaces unless you know the property has been increased.
Because totalSize can be truncated, using start >= totalSize as a termination guard is unsafe. The most robust approach is:
willPaginate: false.
results array is empty.Both conditions reflect the API’s current state and are unaffected by the confluence.query.max-results cap.
Offset‑based pagination (start/limit) is sensitive to concurrent inserts or deletes. A new page inserted before the current offset will shift every subsequent item down one position, causing duplicates or missed items. Deletions have the opposite effect. The API does not provide a cursor or immutable ordering to shield against this drift.
The standard /rest/api/content endpoint does not expose a cursor. You can supply a sortBy parameter (e.g., createdDate, lastModified) to impose a deterministic order, but the offset still moves if the underlying set changes. For truly stable iteration you would need to snapshot the set first (e.g., export a list of IDs) or use a custom query that locks the result set.
confluence.query.max-results value. If it is 10,000 and you expect more pages, plan for capped totalSize.
limit (e.g., 1,000) and increment start by that amount.
willPaginate becomes false or the results array is empty.
sortBy clause to reduce drift, with the understanding that it does not eliminate duplicates.
To fine‑tune the strategy, it would help to know the current value of confluence.query.max-results in your instance. If you have increased that property, totalSize may be accurate for your space.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.