Destroy and Specific RateLimits

TweetinviApi · 2014-11-07T09:51:43.185Z

Hi,

RateLimits strikes back! Following the rate limit post I made yesterday, I am writing another post to get even more information concerning the RateLimits.

I have 2 questions, one concerning the destroy methods and one concerning RateLimit that I could not map to endpoints.

DESTROY

All the destroy queries seems to be rate limited as per the documentation (e.g. https://dev.twitter.com/rest/reference/post/direct_messages/destroy).

But I have not been able to find any rate limit documentation concerning their values nor could they be found in the rate_limit_status.
Do you have any information concerning these queries?

WHERE IS THE RATE LIMIT’S QUERY?

I have been able to associate most RateLimit returned by the rate_limit_status to a query but I could not figure out, which URL the following were referring to.

/account/login_verification_enrollment (I do not know what this is related with, as another RateLimit exist for VerifyCredentials
/device/token (I tried calling https://api.twitter.com/1.1/account/update_delivery_device.json?device=none) without the rate limit being affected
/direct_messages/sent_and_received (there already is one for each and neither getting the message sent or received seems to affect this value)
/friends/following/ids
/friends/following/list
/help/settings
/statuses/friends
/users/derived_info

I know this is a lot of information to ask.
Thank you for any help.

Linvi

TweetinviApi · 2014-11-10T10:32:10.540Z

Anyone got this information?

andypiper · 2014-11-10T13:24:29.860Z

Hi Linvi, we haven’t had a chance to dig into these specific questions yet. As I mentioned in the other thread, we are aware of the fact that not all of our rate limits are currently documented and that they are not all in a consistent format in the same place. This is on our list to improve, but there is no current timescale for completing this work.

We really appreciate you bringing these endpoints to our attention as lacking in documentation on rate limits, and we’ll work on making this better in the future.