There are really three kinds of rate limiting on Twitter – one of which we don’t call rate limiting.
First: user-based allowances for write actions – these have nothing to do with applications. Users can tweet, retweet, reply, DM, follow, favorite and all of that stuff. The user intrinsically has an allowance to how often they can do that. How many times they can tweet or DM “right now” isn’t a value exposed by the API at all. An application won’t know that a user doesn’t have any more allowance for tweeting or replying or retweeting until they attempt the action action.
The second and third kind of rate limiting are API rate limits. They only apply to read actions and each possible read action has it own limit divided from other read methods.
Second: app-only auth rate limiting – this is where you’re explicitly using a form of authentication that does not involve an end user. For each API method that you call, your application is allowed a certain amount of requests (different for each method) per 15 minutes in this context. The rate limiting here is conservative and meant to be used for very simple use cases or as an additional reserve for…
Third: user-based rate limiting – this is where you’re using OAuth 1.0A and access tokens representing your users. Just like app-only auth, each possible read method has its own rate limit associated with it. This rate limit applies in 15 minute windows and is unique for each access token you have representing your end-users.
