GitBook Content API: list vs search pagination limits for large exports

Goal

Export a complete dataset from a GitBook space using the Content API, choosing between the standard list endpoints (pages, revisions) and the search endpoint for discovery.

Constraints and uncertainty

List endpoints accept page and limit parameters and return pagination metadata with a next-page marker. The search endpoint accepts a limit parameter but its pagination depth is not clearly documented; it may only return a bounded first page. Server-side limit clamping means the effective limit must be read from each response. Page-based iteration lacks a stable-cursor guarantee, so collection changes between requests can skip or duplicate items. Search relevance ranking may also reorder results across pages, compounding instability.

Questions

1. Does the search endpoint expose a next-page marker or cursor that allows deep pagination comparable to list endpoints?
2. What are the current default and maximum limit values for each endpoint type, and are they enforced with clamping or validation errors?
3. For a dataset exceeding 10,000 items, which endpoint path reliably supports full enumeration without gaps or duplicates?