Definition and scope
How Pagination Markers Work in XRPL APIs addresses a distinct part of developer guides. Retrieve large result sets safely using opaque continuation markers.
Reliable XRPL applications do more than submit JSON. They choose appropriate server connections, manage pagination and subscriptions, construct and sign transactions safely, interpret tentative and validated results, and recover cleanly from interruption. Applications must preserve exact amounts, protect signing material, handle retries idempotently, and reconcile against validated ledgers.
How it works
Paginated XRPL methods return an opaque marker when more results are available. The client sends that exact marker with the same request context until no marker remains.
- marker: verify this field, object, or component against the cited protocol documentation.
- limit: verify this field, object, or component against the cited protocol documentation.
- pagination: verify this field, object, or component against the cited protocol documentation.
- validated ledger: verify this field, object, or component against the cited protocol documentation.
Practical example and checks
An indexer stores each page before requesting the next, preserves the marker without decoding it, uses a fixed validated ledger when supported, and resumes safely after interruption.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
Markers are method- and server-context values, not portable offsets. Changing filters or querying a moving current ledger can create inconsistent multi-page results.
Applications must preserve exact amounts, protect signing material, handle retries idempotently, and reconcile against validated ledgers.
Current network status
Network-independent guidance. This guide explains an operational or representational concept. Confirm live server values and service-specific behavior before relying on it in production.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.