RateLimit in documentation is not reflected in rate_limit_status

documentation
#1

Hello there,

I am currently developing a RateLimitAwaiter for the TweetinviAPI. This class will be waiting for the rate limit to have the required number of remaining operations to execute a query.

Once more, I am confronted to the documentation being inconsistent.
Lets take the example of DIRECT_MESSAGE_NEW (https://dev.twitter.com/rest/reference/post/direct_messages/new). In the description of the contract it is specified that it is rate limited.

Now if you go on the rate limit chart, it is nowhere specified how it is limited. Moreover when accessing the rate limit from the REST API, it is not returning any information concerning this limitation. (https://api.twitter.com/1.1/application/rate_limit_status.json)

This is the case for multiple endpoints and I would need to know whether it is limited or not? And if it is limited, where can I get the rate limit information?

Kind Regards,
Linvi

"Rate Limited" after Temporary Write Privilege Revocation
#2

Thanks for the question Linvi.

This is something that we need to clarify, and it is on my radar to get that done.

If you look at this recent discussion on another thread, you’ll find that these limits are posted elsewhere at the moment. We ought to fix that. There’s much more detail in that other conversation, but in summary:

The rate limits header and rate_limits_endpoint endpoint are unlikely to change to include these per-user limits in the near future.

Where are the destroy rate limits?!
Destroy and Specific RateLimits
#3

Hi,

Thank you for this response which is quite helpful.
Though I do not understand how I can retrieve the rate limit information of the second part (POST).

Without any endpoint to get the POST rate limits, you cannot prevent the users from hitting a RateLimit of a specifc endpoint, you must execute the WebRequest and wait for it to fail? Is there absolutely no way to know the number of operation remaining for a specific set of credentials using the REST API?

If the last answer is yes, I think it is a missing feature from the API. Forcing developers to be blind in regard to the POST rate limits and forcing them to try and fail is not something that I find being a good practice, this should be the exception rather than the rule.

Please let me know if I am correct.
Kind Regards,
Linvi

#4

The POST / create limits are documented on the support pages I linked above.

“For instance, a user can post 2400 tweets per day, broken down into hourly intervals.” - so you can essentially code this knowledge into an app.

However, even if you were to code to a notional limit of 100 tweets per hour, for example, you might still be rate-limited if the system detected abnormal behaviour (via adaptive rules enforced by something like botmaker).

This is one of the reasons why there are no endpoints that expose the rate limits for object creation / modification. It is much easier to rate-limit the read operations on the system.

We definitely want to clean up the documentation around this whole area so that developers have a better view into these limits in a single place; but at the moment there are no plans to add an API feature to expose the POST limits. Thanks for the feedback on this, though - we do take these kinds of discussion into consideration as we plan ahead.

#5

Thank you for your help.

May I suggest that you add a field to the RateLimit called status. This would represent whether a specific set of limits has been blocked and the reason.

This would allow developer to have more vision over the POST rate limits while giving you the ability to detect and block abnormal behaviour, as well as letting the users know why they have been blocked.

In the meantime I will work with currently documented rate limits for post.

Thanks again.
Linvi

#6

Thanks for the great idea, we will certainly consider it for a future API update, but we are unable to commit to any timescale for implementing such a feature. Good luck - and thanks for the great work on your Twitter library! The C# developer community certainly benefits from your efforts.

closed #7