Too many requests in this time period. Try again later.

[J.D.]

Today I started getting this error, even only after a handful of API
calls. Is this a new change? I've tested with two accounts, one that
is whitelisted and another that is not. I'm getting this from both
accounts after only 30 or 40 calls.

403 "Too many requests in this time period. Try again later."

[Kevin Mesiab]

How quickly are the 30-40 calls issued?

--
Kevin Mesiab
CEO, Mesiab Labs L.L.C.
http://twitter.com/kmesiab
http://mesiablabs.com
http://retweet.com

[J.D.]

Hi Kevin,

It's downloading info for a social graph (all the users followers), so
fairly quickly. Do I need to add a sleep between calls to statuses/
followers?

J.D.

[J.D.]

WRT the sleep, I've never had to in the past. It just started failing.

[Kevin Mesiab]

Regarding a sleep between calls, until someone from Twitter pipes in it would be worth a use case test, yes. 

On Fri, Jul 17, 2009 at 1:38 PM, J.D. <jeremy....@gmail.com> wrote:

WRT the sleep, I've never had to in the past. It just started failing.

[winrich]

are you calling the verify credentials call? they started limiting
that call to 15 requests per hour due to an attack vulnerability. I
started getting that error today too.

[Jesse Stay]

Me too. I think more developers need to know about this - I see many complaints of "password issues" on Twitter search recently.

Jesse

[J.D.]

> are you calling the verify credentials call? they started limiting
> that call to 15 requests per hour due to an attack vulnerability.

Ah yes, as a matter of fact I am. I was calling it each time my
application started, I'll refactor that. Thanks!

J.D.

[J.D.]

I can see why this api should be limited, but it seems (from the
outside, I'm sure maybe there are other reasons) like if the
credentials are correct, it shouldn't count against the limit. Only
limit if the attempts are bad (someone is fishing).

J.D.

[Jesse Stay]

I asked the same thing of Alex - waiting to hear back. This method is still very useful for verifying users haven't changed their passwords since the last time the script was run.  Also, in Alex's own words, OAuth isn't ready for production yet, last I heard so probably shouldn't go that route either (or is it?).

Jesse

[Swaroop]

This is occurring with OAuth as well. verify_credentials is now being
limited to 15 calls/hour. I really wish they had informed us in
advance, at least not a day before weekend.

On Jul 18, 11:07 am, Jesse Stay <jesses...@gmail.com> wrote:
> I asked the same thing of Alex - waiting to hear back. This method is still
> very useful for verifying users haven't changed their passwords since the
> last time the script was run.  Also, in Alex's own words, OAuth isn't ready
> for production yet, last I heard so probably shouldn't go that route either
> (or is it?).
> Jesse
>

[Chad Etzel]

Can someone verify if it is being limited even if the credentials are *correct*?
-Chad

[winrich]

yeah, its being limited even when i call it with a valid OAuth sig.

On Jul 18, 11:39 am, Chad Etzel <jazzyc...@gmail.com> wrote:
> Can someone verify if it is being limited even if the credentials are *correct*?
> -Chad
>

[Jesse Stay]

Yeah, to tell you the truth the no notice thing has completely ruined my weekend trying to re-factor broken production code thanks to this.

Jesse

On Sat, Jul 18, 2009 at 4:46 AM, Swaroop <rh.sw...@gmail.com> wrote:

[Doug Williams]

All,
This change was thrown out on the pipeline rather quickly. We admittedly should have done a better job voicing this rollout well in advance though it was not a normal week at HQ for a number of very public and private reasons.

Users are now limited to 15 calls to account/verify_credentials per hour. We have not received an abundant number of emails stating that these limits are causing problems. This is not to say that there are cases where this is inconvenient, but in aggregate very few developers have contacted me with issues. If you feel that 15 requests per hour per user is too low, please help us update this policy and share details of your use case.

Chad, et. al, I will follow up with the answer to your question (if this limit affects calls to the method with correct credentials) when I have a moment to speak with Alex.

Thanks,
Doug

[Jesse Stay]

Thanks Doug. I'm anxiously looking forward to the answer to that question - it will make things much better for those of us running scripts on the backend who want to verify when our users have changed their passwords with Twitter so we can notify them to change with us as well.  

I understand this week's  circumstances, but it isn't the first time this has happened.  The more notice Twitter can give us on any change you make, especially with limits, the better - my entire weekend was spoiled (and I'm visiting my parents in Boston) trying to re-factor code because of this.  Is there any way Twitter can consider doing what Facebook is doing and release new changes into a beta environment for a week before it goes live?  That would at least ensure we always have a week to test our changes, regardless of notice.  The less surprise, the better, IMHO.

I hope this sounds constructive, more than critical - it is intended to help improve, rather than just troll or criticize.  I hope it is taken as such.

Jesse

[Chad Etzel]

On Mon, Jul 20, 2009 at 1:23 PM, Doug Williams<do...@twitter.com> wrote:

> If you feel that 15 requests per hour per user is too low, please
> help us update this policy and share details of your use case.

One use-case where I can see this being a bottleneck is testing new
apps during development (especially OAuth since verify_credentials is
the 'preferred' way to get user info once they return). I can easily
login/logout a hundred times in an hour if I'm trying to test
something related to the login flow. Of course, the point is moot if
successful logins don't count against the limit.
-Chad

[Scott]

Doug, I would also like to know if this can be changed to trigger only
on incorrect credentials. I check to make sure a user hasn't
deactivated my app connection every time they load a page, so these 15
calls gets used up rather quickly. I've started to get some
complaints due to this error and would prefer not to rewrite my code.

[Jesse Stay]

The problem is so long as they are complaining on some of our apps they are complaining on all our apps and there's no way of telling which app caused it.  In addition, it would be nice if OAuth-authorized apps were exempt from this limit.  Stopping a potential cracker is as simple as turning off their OAuth in that case.

Jesse

[Scott]

I agree Jesse. I don't see why this should be imposed on OAuth apps.
It's not likely somebody is going to guess both the token and the
token secret.

[Doug Williams]

We are going to roll this change back and re-evaluate how we can
better accomplish our goals. There are problems and shortcomings of
this strategy that we need to mitigate.

I will update this thread when we have a concrete plan to share. I do
not have a definite date or time for the rollback but it should be
soon.

As always, thanks for your patience.

Thanks,
Doug

[Scott]

Great news Doug!! It certainly has its shortcomings as it stands
now. I did change some of my code to limit its use, but I still need
to ensure my logged in users have maintained their connection.

[Martin Omander]

Doug,

Thanks for letting us know about the new request limit. I was worried
something was wrong on my side. Like the others are saying; it would
have been nice with a heads-up.

Cheers,

/Martin

[Doug Williams]

Martin,
The change certainly went out prematurely which is admittedly a
mistake on our end. I will have details tomorrow morning to share
about our fix.

Thanks,
Doug

[Doug Williams]

Let's bring the discussion on the update to the new thread:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/2d68c74567bc9809

Thanks,
Doug