Twitter API v1.1 ↔ v2 Pagination: Rate‑Limit Impact of Reusing next_token

Problem Overview

The new Twitter API v2 introduces an opaque next_token cursor for all list endpoints. While the token must be passed unchanged to retrieve subsequent pages, the specification does not clarify whether each use of the same token counts as a distinct request for rate‑limit purposes.

Goal

Determine how repeated or delayed use of an identical next_token affects the rate‑limit counter for app‑only authentication, and how this behavior aligns with the legacy v1.1 max_id and since_id parameters.

Uncertainties

• Is a request with a previously seen next_token considered a new request that consumes a rate‑limit slot?
• What is the inclusive/exclusive boundary mapping when translating max_id/since_id to v2’s pagination_token and start_time/end_time?
• Does the beta search/all endpoint treat cursor reuse differently from search/recent?

Questions

1. Does each request that reuses a next_token decrement the x‑rate‑limit‑remaining counter, even if the token is identical to a previous request?
2. When migrating from v1.1 to v2, how should max_id and since_id be mapped to pagination_token, start_time, and end_time to avoid off‑by‑one errors?
3. Is there a documented difference in cursor handling between the /tweets/search/recent endpoint and the /tweets/search/all beta endpoint?