Friggin-A, man. That was it. The call I was using allows both unauthenticated AND authenticated calls. I was baffled because I thought I was authenticating, but the real issue is that I was using the wrong DOM type and couldn't authenticate. There's 16-hours of trouble-shooting down the drain.
Thanks. Nick On Jun 16, 12:51 pm, Matt Sanford <[email protected]> wrote: > Hi there, > > Since moving servers reset things it sounds like it's using the > unauthenticated limit. We do that if there are no credentials or if > the credentials are incorrect. You also mention that statuses/update > (note the plural)is giving you a 401. That would make sense if the > username/password were incorrect as well. Is this rate limit issue > happening for an API method that allows unauthenticated access? If so > it sounds like it would all fit. > > Thanks; > – Matt Sanford / @mzsanford > Twitter Dev > > On Jun 16, 2009, at 5:14 AM, betweeted wrote: > > > > > I began noticing some strange behavior - 401 errors on status/update > > calls saying "We were unable to authenticate you". > > > I racked my brain, checked and rechecked the username and password, > > then finally I decided to create a small script to check my ratelimit > > at account/rate_limit_status.xml and sure enough, I was at 0. I > > waited an hour, and I was at 54. Within minutes, however, I was back > > to 0. > > > So, naturally I thought some bot had hijacked my scripts and was > > eating up my api calls. I downloaded server logs. There is no > > excessive activity at all. In any case, all my calls are > > authenticated, so they should be using the users api limit, not my > > servers. > > > On a hunch, I uploaded the same rate limit checking script to a > > different host that I have access to (with a different IP). Guess > > what? 100 hits remaining. > > > In fact, whether I authenticate the request or not, I'm still at 0 > > hits remaining whenever I try that same script on my server. But, if > > I try it somewhere else, I have all 100. Am I blacklisted? > >
