Concurrent Request Impact on Twitter API v2 Rate Limits

Goal

Determine how concurrent read requests to Twitter API v2 affect latency and rate‑limit enforcement, specifically whether bursts are smoothed or strictly rejected, and how app‑level versus user‑level quotas interact.

Constraints & Uncertainty

Twitter API v2 applies fixed‑window limits for each endpoint, with separate quotas for app‑level and user‑level authentication. When multiple clients issue requests in parallel, the platform’s documentation does not clarify whether in‑flight requests are counted as separate increments within the same window or whether a server‑side smoothing mechanism mitigates burst‑induced latency spikes. Free tier accounts have significantly lower quotas than paid tiers, potentially altering observed behavior.

Specific Questions

• When concurrent requests are sent to the same read endpoint, does Twitter count each in‑flight request against the current rate‑limit window independently, or does it apply any form of burst smoothing?
• How do app‑level and user‑level rate‑limit counters interact during a burst of concurrent traffic—does exceeding one automatically trigger a 429 even if the other counter remains within bounds?
• Is there a documented difference in latency spikes or 429 response patterns between free and paid tiers under high concurrency?