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

Answer

1. Yes, each request that includes a next_token (even if identical to a previous one) decrements the x‑rate‑limit‑remaining header for app‑only authentication.
2. To map v1.1 parameters without off‑by‑one errors: set start_time to the timestamp of the tweet immediately after the since_id value (inclusive) and end_time to the timestamp of the tweet at the max_id value (exclusive). If you are not using time‑based bounds, rely solely on the pagination_token (the v2 cursor) and omit start_time/end_time.
3. The beta /tweets/search/all endpoint uses the same pagination_token mechanism as /tweets/search/recent; there is no documented difference in how cursor reuse affects rate‑limit counting.

Likely explanation

Twitter counts each HTTP request toward the rate limit, regardless of whether the pagination token repeats. Re‑using a next_token therefore behaves like any other request and consumes one slot from the quota.

Confirmed facts

• Every response includes rate‑limit headers (x‑rate‑limit‑limit, x‑rate‑limit‑remaining, x‑rate‑limit‑reset) reflecting the total number of calls made in the current window, independent of token repetition.
• In v1.1, max_id is inclusive (tweets with ID ≤ max_id) and since_id is exclusive (tweets with ID > since_id).
• In v2 recent/search, start_time is inclusive and end_time is exclusive. Mapping as described above preserves the same inclusivity/exclusivity behavior.
• The beta search/all endpoint shares the same pagination token behavior as search/recent.

Steps to verify (if needed)

1. Make a request to /2/tweets/search/recent with a valid query, capture the returned next_token and the current x‑rate‑limit‑remaining value.
2. Immediately issue a second request using the exact same next_token (no other parameter changes) and read the new x‑rate‑limit‑remaining. It should be exactly one less than the first value if the request succeeded.
3. Repeat the test with a v1.1 endpoint (e.g., GET statuses/user_timeline) using max_id or since_id and confirm each request reduces the remaining count, showing parity between versions.

Missing diagnostic detail

If you are operating under an elevated access level or a custom rate‑limit arrangement, please confirm your specific product tier, as behavior could differ for those cases.