Inconsistent REST API rate limit headers



The rate limit docs mention using the following headers to extract rate limit information: X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset. Our application has been successfully doing this for a long time, caching the results and making sure we never actually hit the Twitter API rate limits.

However, just in the last day, we’ve noticed that the values for these header fields are sometimes inconsistent. For example (irrelevant headers truncated), from two separate responses to separate requests:

{ "x-rate-limit-limit"=>["timelines_api", "900"], "x-rate-limit-remaining"=>["899"], "x-rate-limit-reset"=>["1478709732"]}
{"x-rate-limit-limit"=>["900"], "x-rate-limit-remaining"=>["00a1265b0009be9b", "899"], "x-rate-limit-reset"=>["1478709146"]}

Most requests have just a number (represented as a string) in both the x-rate-limit-limit and x-rate-limit-remaining fields.

I haven’t seen anything in the docs that mention that the rate limit fields can contain values other than numbers. Nor do I have any idea what the “00a1265b0009be9b” string is referring to.

This apparent change to the API (bug?) broke our code that parses rate limits from headers. A fix seems easy, but I’m reluctant to fix it in an ad-hoc manner without any docs indicating what to expect in these fields.


Here’s another one. In this case, the numbers in the array (i.e. order in which the header value appears) aren’t even in the same position, so I can’t just say “okay, parse the first string as a number, and that’s the value we want”.

{"x-rate-limit-limit"=>["timelines_api", "900"], "x-rate-limit-remaining"=>["899", ""], "x-rate-limit-reset"=>["1478710797"]}


This looks very similar to this issue. @andypiper will probably want to take a peek at this as well.