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. -Zach 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: http://groups.google.com/group/twitter-development-talk
