Just got into the office and sure enough I got an email of a 400
response last night at 12:59 AM. From what I can tell the last request
before the 400 was at 11:55 PM and had an expiration time of 11:57 PM.

This does still match up with my first request after midnight theory,
but I noticed something else interesting in the header. The date in
the header is "Sat, 15 Jan 2011 06:59:21 GMT", which would be 12:59:21
AM CST. The X-RateLimit-Reset is 1295074762, which is 12:59:22 AM CST.

It's possible that there was a request done after 11:57 PM that I'm
not tracking and that our request was just lucky to be sent one second
before our reset, but I find the one second different a little too
close to ignore.


On Jan 14, 9:32 am, Zach Gardner <z.gard...@hotmail.com> wrote:
> We've been having problems recently with going over our rate limit
> when making API calls. We do a lot of server side caching of the
> responses we get from the API, so I was curious why we were going over
> our limit. I setup our application to record the headers we receive
> each time we make an API call, and found something interesting with X-
> RateLimit-Remaining:
> When we make our first API call in a while a little before midnight,
> we get a new rate limit remaining and new expiration time. But as soon
> as we make a call to the API after midnight, our rate limit goes to 0,
> so we have to wait till the expiration time to start making calls
> again.
> Yesterday at 11:50 PM CST we made the first call to the API after our
> expiration time passed. Our X-RateLimit-Remaining was 149 out of 150
> because that call used one of our allotted 150 per hour. The next call
> we made to the API was this morning at 12:10 AM CST, but our X-
> RateLimit-Remaining was 0. It's entirely possible that I didn't add
> the header tracking to another place we do API calls, but I doubt we'd
> have that much traffic at that time of the day to use 149 calls in 20
> minutes.
> For the past few weeks I had it set to email me when the API returns a
> 400 Bad Request header. I've gotten one on the 11th at 12:17, the 10th
> at 12:37, the 8th at 12:22, and the 6th at 12:23 AM CST. (Google
> crawls our site around midnight our time, and our server side caches
> have expired by that time, which is the origin of most of the
> requests.)
> I found something interesting while looking through our logs for the
> 12th. We made an API call on the 11th at 11:35 PM, which used our
> 146th call per hour. The expiration time for that hour was the 12th at
> 12:04 AM. The next call we made was on the 12th at 12:35 AM, after our
> expiration date. Our rate limit remaining was back at 149 out of 150
> with an expiration at 1:35 AM as expected.
> I was wondering if anyone has experienced something similar, or am I
> just missing something entirely. I can provide the headers in full if
> necessary..
> Thanks,
> -Zach

Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 

Reply via email to