Does Twilio next_page_url guarantee consistent pagination when resources mutate mid-iteration?

When bounding a query across a very large Twilio resource list—such as millions of message or call records—the goal is to retrieve every item exactly once without duplicates or gaps, even if new records are inserted or existing ones are deleted while the iteration is in progress.

Twilio list responses include a meta object with next_page_url and previous_page_url, which the documentation presents as the recommended traversal mechanism. Explicit page and page_size parameters are also supported, but Twilio does not guarantee a stable sort order across separate list requests. Because page behaves as an offset hint, concurrent mutations can shift the underlying dataset and cause items to be skipped or yielded twice. The opaque next_page_url cursor is tied to the original query filters, so altering parameters after receiving the token may produce an inconsistent result set. Helper libraries expose page(), stream(), and list() methods that wrap the pagination loop differently, affecting memory footprint and network behavior.

Given these constraints, does the next_page_url cursor provide stronger consistency guarantees than explicit page parameters when the resource list is actively mutating, or do both approaches require application-level deduplication? Which helper library method is better suited for safely iterating a mutable, high-volume dataset under Twilio's rate limits? Are there documented product-specific differences in pagination behavior that affect whether next_page_url remains the safest choice for this pattern?