Acceptable Rate Limits



Hi All,

I have a general question. Is a 10 minute interval an acceptable rate limit to post to a Twitter timeline using the APIs? Can someone use a service to schedule a post to their time line and have that tweet be posted every 10 minutes an acceptable amount of time between posts?



I’m not sure whether this is the correct question to be asking.

For posting Tweets, there are account limits (rather than fixed 15 minute rate limit windows that apply to the read / GET API endpoints) that would dictate roughly how often the statuses/update API can be driven.

There is also an automation policy that lays out how automated services should operate on the platform, and provisions in the developer policy and in the Twitter Rules that specify that repeated and spammy posts are not wanted on the platform.

The antispam and abuse system is automated and adaptive, and frequently detect and take action on aggressive repeated postings. It does so in a manner consistent with the policies linked above.

Overall, that’s not quite the same as just answering “is it OK to post a Tweet on a schedule every 10 minutes?”, because in terms of account limits and API capabilities, yes you can write an app that does that. You should think about what the app you’re writing is achieving in the broader contact of the platform.

Thank you.


Thank you Andy for responding. We have reviewed the policies about how often (falling within the account limits) statuses can be done and programmed based on those numbers. Even when doing so, we were write restricted on the app.

We tried to explain that an end user’s token/secret would not write/post more than 7 times within a 15 minute window, when the policies dictate that a user’s statuses/update is allowed 25 posts within a 15 minute window. But we were told it’s “too aggressive”, even when it fell within the policies set forth by Twitter.

We have also reviewed the policies closely regarding automation and spam as defined in the Twitter Rules

We tried to get a response from Twitter that would help us to adjust our coding that met the requirements as Twitter saw fit, even though the existing code still fell within the limits of what Twitter states in their policies. But the ticket got closed out and we couldn’t reply any further to it.

When you mention “aggressive repeated postings” does that include retweets as well? If different people have scheduled the same retweet using their own individual token/secret combo is that what you mean by ‘repeated postings’ - or do you mean the same post on different accounts? Because our system allows people to schedule retweets.

We just wish someone from Twitter would take a moment to look a little deeper and see that we have set this up so that it meets the requirements of automation, meets the requirements of API limits per an individual’s account, meets the requirements of not being spammy content and help us to determine what is an acceptable rate limit. We have internal rate limiting in place that controls how quickly statuses/updates happen, and even at a 2 minute rate limit, which calculates to just 7.5 updates within a 15 minute window, it was “too aggressive”.

I ask that you not close out this thread until we could get some sort of definitive answer as to how quickly we can send out statuses/updates to a user’s account. We just want to get this resolved, that’s all.

I also wanted to mention that presently write restrictions are removed, and we’ve made some adjustments so that the lowest time interval is 10 minutes apart to help with not being so aggressive. But again, the policy says that 2,400 updates are allowed in a day, which calculates down to 25 statuses/updates are allowed within a 15 minute window, and we aren’t allowed to do 7 within that window without being write restricted.


It would be likely to trigger the antispam system if multiple accounts were attempting to game Twitter trends, or otherwise aggressively boosting content. This is not a question of rate or account limiting.

We are not able to answer this in a binary manner. The antispam system automatically detects overuse of retweets, automated link sharing, and similar content being posted. You should consider that if the majority of content in a timeline is scheduled retweets, then that’s probably not high quality content.

That is not “the policy” - that is a specific account limit.

The policies to consider are the automation rules, Twitter rules, and developer policy. None of those make mention of specific limits. The Twitter Rules specifically mention that our antispam systems evolve over time, and also make clear that if accounts are behaving suspiciously then they may be temporarily removed from the search index.

If an app is only posting links, hashtags, or making unsolicited mentions, then it is highly likely to be limited. These policies are enforced via a universal set of rules across the board.


Thanks again for some clarifications Andy, it’s appreciated.

I’d like to see if we could get this question answered:

If the app was write restricted, and someone went through the process to submit their information about the app, when that person finally receives a response as to why the app was write restricted, would they receive an answer that has “all” the reasons as to why the app was restricted?

For example:

Your app was found in violation for x, y, z

Again, the only thing that was mentioned to us was due to aggressive statuses/updates. Nothing else was given.


In my experience, the platform support team provides specific reasons when an application is in violation of one of the policies described above. Returning to the subject of this post, rate limits and account limits are hard limits enforced in the Twitter API endpoints; the antispam systems detect aggressive or unwarranted status posting and retweeting behaviour that violate platform policies.

I can assure you that our support agents do review tickets and provide answers as clearly and precisely as they are able to (bearing in mind everything I mentioned above about automated systems and the actions they will take).

As you may be aware, we are unable to enter into detail dialog about specific apps via these forums, so you’ll need to use the support form for further help with an individual case. Closing this out as I’ve now been as detailed as possible in supporting your questions. Thank you.