Rate Limit Query - Are there options other than server side caching?



I work in Digital Signage where as well as advertising we display customer information such as traffic, weather, news and Twitter feeds. Recently we’ve been getting more requests to displays Twitter feeds and have hit the point where the rate limit for our consumer key/access token is being exceeded.

I understand that trying to circumvent the rate limits if frowned upon to say the least and I want to assure you that I am not trying to find ways round the limits, rather I want to make sure I understand the legitimate options properly before deciding on a course of action.

Each of our signs that displays a Twitter feed is essentially using read only application level access to download and display Tweets from a user’s Timeline or from a List. Based on this, each time a sign requests the latest Tweets it counts against a single rate limit and given that we have more signs using the Twitter API in a 15 minute window than the number of requests allowed by the rate limit, we are always exceeding the limit.

A possible solution to this problem is to implement some sort of caching mechanism whereby a single Twitter API access point runs on one of our servers, gets the Tweets for all possible Timelines and Lists that our signs require, stores the Tweets on our servers and then the signs get the Tweets from our servers rather than via the Twitter API.

Before spending the time implementing such a caching solution I was hoping someone could let me know whether there are other possibilities. For example:

  • Is it possible to get an access token per sign without also needing to setup a consumer key or application per sign and can it be automated?
  • Is it possible to pay for increased rate limits?
  • Anything else I haven’t thought of …

Thanks for your time in advance


The solution you outline is what I would recommend and the best way for you to manage Twitter content (or any content) on your signage. This will allow you to provide additional data to your signs in addition to Twitter content and is much more scalable. I would not recommend an access token per sign in your case.


Thanks for your help, I’ll go down the caching route then.