Lack of X-Rate* when tweeting and sending a DM

[bobber205]

Recently there was a blog article about how to best work with rate limits/limiting on Twitter. In that post twurl was talked about and I gotta say it’s an AMAZING tool. I highly appreciate it existing.

That blog post also said that using the " -t " option will give you all the request headers where you can see the rate limited related headers that are returned.

This doesn’t seem to be true for the /update and /direct_messages/new endpoint. (I did see it for the /upload endpoint and getting a list of DMs endpoint fwiw)

We’ve had lots and lots of trouble with rate limits with an account that never used to have them, specifically with DMs
Everything I read says there isn’t a limit on DMs but we definitely hit it yesterday (around 12,000 in 5 hours), and received ban on DMs that lasted for at least several hours.

I can’t work around limits that I don’t know or ones that are constantly changing week to week.

How else can I find out what our twitter per hour/15 minute limit is? What about DMs?

Here’s some examples of posting a DM and the headers returned https://gist.github.com/bobber205/573cf76d8d548f04d448ebb4f020d007 from two different accounts

Thanks for all the help! <3

[andypiper]

First of all, really glad you liked the tips blog post and are enjoying twurl! That’s exactly what we were aiming for when we put it together.

The issue you’re hitting here is this one:

Also, don’t forget that read (GET) endpoints provide this information, but write (POST / DELETE) endpoints are bound to Twitter’s user account limits, and are treated differently by the limiter front-end.

Any POST endpoint is an account limit, rather than a rate limit. You can read about those here. They are also adaptive for spam-related reasons, so although there’s a blanket 2400 Tweet limit across 24 hours, clearly the majority of users will Tweet within more of an 8–12 hour period inside that 24 hour window, so the system allows for that; equally, firing off 100 Tweets in a 5 minute window programmatically is not realistic, and likely to indicate unusual behaviour, so would be limited by the antispam and automated machine learning tools.

Unfortunately in the latter cases there’s no way for the API to provide you a completely predictable way of measuring what is possible via either the HTTP headers or via the configuration endpoint.