Rate limit pool consolidation under shared app-only and user context credentials

Direct answer

X API v2 does not consolidate app-only and user-context requests into a single rate-limit pool. Even when the same application credentials are used, the service maintains separate counters: app-only bearer-token calls draw from an app-level bucket, while user-context calls draw from a per-user bucket tied to the authorizing user. A 429 response's Retry-After header reflects the remaining window of the pool that the throttled request belonged to—app-level for bearer-token calls and per-user for user-context calls. The rolling 15-minute window is tracked independently for each pool, so consumption under one context neither advances nor resets the other context's window.

What is confirmed vs. what is likely

Confirmed: The rate-limit key is the principal (the app itself versus the authenticated user), not the app ID alone. Response headers such as x-rate-limit-remaining and x-rate-limit-reset describe the bucket that the current request consumed. If you exhaust one context, the other can still succeed against the same endpoint.

Likely explanation: Because app-only traffic represents the application acting autonomously and user-context traffic represents an individual authorizing user, isolating the counters prevents one principal's usage from silently consuming another's quota. Some endpoints also publish different caps for app auth versus user auth, so the same endpoint can have distinct limits and reset times depending on the credential used.

Uncertain / verify: The 900-per-15-minute figure and the "standard access" tier name may be outdated; X API tier names and numeric limits have changed. Treat any specific cap as unverified until confirmed against current documentation. Exact accounting for OAuth 1.0a versus OAuth 2.0 PKCE user tokens has varied historically, so confirm the current behavior for your OAuth flow.

Steps to verify pool separation in your app

1. Issue a few requests to the same endpoint with app-only bearer authentication and record x-rate-limit-remaining and x-rate-limit-reset from each response.
2. Repeat immediately with user-context authentication and compare the two header sets. Different remaining counts or reset timestamps confirm independent pools.
3. Exhaust one context—for example, drive user-context calls until a 429—and confirm that app-only calls to the same endpoint still succeed. Continued success indicates isolation.
4. When a 429 occurs, compare its Retry-After value with the x-rate-limit-reset header in the same response; they should align for the throttled context. Repeat for the other context.

One diagnostic detail that changes the recommendation

Which OAuth flow are you using for user-context requests—OAuth 1.0a or OAuth 2.0 PKCE? If you are on OAuth 1.0a, verify whether the per-user pool is keyed by the user ID alone or by the user-and-app pair, because implementations have differed. If you are on OAuth 2.0 PKCE, confirm whether public-client constraints alter the app-level bucket. Until that is confirmed, the safe operational assumption is to treat the pools as fully separate and to honor the headers of the specific request that failed.