Getting 420'ed for no apparent reason (Streaming API)

niko_tinius · 2016-03-01T12:12:51.654Z

Hi everyone,

I’m experiencing a weird issue with Twitter’s rate limiting. I’m using the REST API to make a single call to /trends/place (which works) to grab the top 5 trends in the US, then I start a connection to the streaming API through the Twython library. I’m using a single TwythonStreamer that connects to /statuses/filter and passes a comma-separated list of the 5 trends I identified as “track” argument.

This was all working fine a couple weeks ago until some colleagues I’m working with ran the code with the same credentials simultaneously, resulting in an increased number of 420 “enhance your calm” errors. To combat the problem, I replaced the actual streamer with a mock object that keeps generating mock tweets and connects to neither the REST nor the streaming API.

It’s been weeks since any of us ran the code outside of “mock mode” – but when I tried to connect today, I was instantly getting 420’ed again – surely something can’t be right here?

I’m happy about any hints on what could be causing this.

Cheers, Niko

andypiper · 2016-03-01T13:59:06.674Z

It sounds like you tried to open several streaming connections with the same App ID and credentials from the same IP address, which may have resulted in your IP or app being blocked. Suggest you raise a ticket via our platform support forms and request assistance there.

niko_tinius · 2016-03-01T20:16:46.788Z

Hi Andy,

thanks for the quick response. It does indeed look like my IP is being blocked, as I was able to run the code when connecting from a different wireless network. I’ve filed a ticket.

On a somewhat unrelated note, I was wondering whether you could help me with the /trends/place endpoint. I assumed that if I passed WOEID 1 (“world”), the 50 trends returned would include the largest trends (by tweet volume) worldwide. What actually happens is that I get a number of trends that, in terms of popularity, don’t even come close to the top trends I have identified in the US (WOEID 23424977). Is this intended behaviour?

Thanks again
Niko