In the documentation GET users/show (https://dev.twitter.com/docs/api/1.1/get/users/show) the request per limit window is 180 but when getting data from GET application/rate_limit_status the returned resource limit of GET users/show is just 15.
This is being rectified soon – when you use the method you’ll see that your HTTP headers indicating rate limit are accurate.
Thanks. I have another question. I have made an API call to statuses/home_timeline, user_timeline, direct_messages, users/show, but the returned data in GET application/rate_limit_status is not updated. Why is that? Is there anything wrong in my API call or is it just a bug on your side?
Awks, I found another error. In GET statuses/user_timeline the request per limit window is 15 but the response headers I received was:HTTP/1.1 200 OK X-Access-Level: read-write-directmessages Content-Type: application/json;charset=utf-8 Last-Modified: Sat, 13 Oct 2012 13:12:56 GMT Expires: Tue, 31 Mar 1981 05:00:00 GMT Pragma: no-cache Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0 Set-Cookie: guest_id="v1:135013397637509390"; Expires=Mon, 13-Oct-2014 13:12:56 GMT; Path=/; Domain=.twitter.com Set-Cookie: lang=en Status: 200 OK X-Transaction: 44a041db1b28b91f X-Frame-Options: SAMEORIGIN Date: Sat, 13 Oct 2012 13:12:56 GMT Content-Length: 56714 X-Rate-Limit-Limit: 180 X-Rate-Limit-Remaining: 179 X-Rate-Limit-Reset: 1350134876 Server: tfe
Which means GET statuses/user_timeline really has 180 requests per limit window. Can you confirm this @episod?
Any updates about this matter?
I can confirm that statuses/user_timeline is supposed to have 180 requests per limit window – I’ve updated the limit documentation to reflect that.
The other issues you’re running into are some rate limit reporting errors with the rate limit status message – we’re still working to rectify those this week – it’s a multi-step process. I’ll update this thread when the most recent kinks are worked out.