Does X API v2 Recent Search Guarantee a Stable Result Set Across Paginated Requests?

Pagination Window Stability in Recent Search

When building an archival or monitoring workflow around the X API v2 recent search endpoint, the practical concern is whether repeated calls with next_token traverse a fixed snapshot or a continuously shifting index. The endpoint is documented to return Tweets from roughly the last seven days, but it is backed by a search index rather than the primary store, which means very recent Tweets may not be immediately visible and the result set is best-effort rather than exhaustive.

Callers who set start_time and end_time can bound the requested window, but those parameters constrain the query itself, not whether the index has finished ingesting every matching Tweet at the moment the request runs. Additionally, Tweets that matched a query but were later deleted or became protected can be missing from subsequent pages even though they existed when an earlier page was fetched. Exact ingestion latency, pagination token lifetime, and per-tier rate limits are version- and tier-sensitive and should be confirmed against current documentation.

Does the recent search endpoint guarantee that all Tweets matching a query will eventually appear in the result set once indexing completes, or is the result set inherently best-effort? When paging through results with next_token, should callers assume the window is fixed at the first request, or should they expect the result set to shift as newer Tweets are indexed or older ones are removed?