420, Enhance You Calm

[AcquireDev1]

Hi,

Any advice on how to avoid getting a 420 error when streaming would be much appreciated!

We have created a Windows App (Twitter client) to show Tweets from a single Twitter Feed, using the streaming API. The app is to be run on several (potentially hundreds) of PCs.

We created a consumer app. on a Twitter account that was created for that purpose. We use the consumer keys from that.

Our Windows App uses the consumer keys to allow a Twitter user to allow access into their Twitter stream. This process gives us Access Tokens. The App uses consumer keys and access tokens to stream tweets.

As far as I can see from the API documentation we are doing everything correctly.

So each copy of the App, running on multiple PCs, is using the same consumer keys and access tokens to show the same Twitter info. i.e. we are creating multiple streams using the same credentials.

But we are seeing lots of 420 “enhance your calm” messages when trying to stream, forcing the App to fall back to polling.

Is the problem here that we are using the same use access tokens on different machines? I admit being totally bamboozled by the documented rate limitations!

Unless I’m missing something, we’d always have the same consumer keys? But if the user access tokens are causing the issue what is the best practice to stream the same Twitter information on lots of different machines?

(It does seem to be the user access tokens as I created a new user account and it connected/streamed OK when just running the app on one PC. Although I can break it if the app it terminated without closing the stream connections.)

Thanks in advance, Matt

[andypiper]

The streaming API is not designed for large numbers of connections - at most I’d expect one or two streaming connections to be connected concurrently, before others would be cut off, and subsequent connections cause a 420 error.

A multi-user version of streams was released as a beta way back in 2011 - “site streams” - but this proved not to be a successful architecture, has been deprecated, and will in the future be replaced by the newer Account Activity API, based on webhook callbacks and with tiered access for large scale usage. That’s also not designed to deliver user timelines.

Unfortunately at this point the best option you’ll have will be to use the polling option to achieve your aims. Rate limits for access to timelines were significantly improved back in November so hopefully that will help your app’s functionality.

[AcquireDev1]

Hi, thanks for that very swift and informative reply!

For now then we can switch back to polling and see how that goes.

And we’ll look into the Web hooks at some point in the future.

Thanks, Matt.