Our service has been down for over 3 days now due to broken API calls.
Still waiting on any information from Twitter about what's going on,
but still in the dark.
About 3 days ago we started receiving messages (incorrectly in the new
error structure) saying "Over the limit for this type of request,
please wait a while and try again" with error code 33 when calling
friendships/destroy. According to the API docs, this call is not rate
limited http://dev.twitter.com/doc/post/friendships/destroy All our
API requests are authenticated with the requesting user.
This happens after about 100 calls. It makes our app completely
unusable. I'm guessing it's a bug, but after 3 days I'm wondering if
anyone else is seeing this problem. As the errors are returned in the
new error structure they didn't appear in our logs at first, so you
might be experiencing this problem and not noticing. The new error
structure returns a set of error messages under "errors" instead of
just a string under "error".
Due to potential abuse, we've begun locking down bulk deletions that were previously unbound. These lack of limits lead to many application suspensions and blacklisting as the lack of a rate limit was often interpreted as "give us all you've got, non stop," in addition to obvious system gaming.
We're unfortunately not yet publishing the limits on these kinds of actions. Though this limit is trickle-down reflected in the API, it's actually a site-wide construct. It's an IP-based limit, and not a user-based limit.
As you'll most likely be able to discover the limits yourself, I'll work on getting these numbers released and hopefully get an X-FeatureRateLimit set of HTTP headers attached to these requests also.
I would recommend developing the following strategy when you run into this error:
- Back off for 5-6 minutes (stop retrying this specific kind of request) - Try the request again. - If it succeeds, great, continue until you're limited again (or work on ways to never get limited, such as preventing bulk actions in your UI) - If it fails again, wait another 2 minutes, retry & repeat.
I think the current limits are pretty reasonable, and the time window refreshes often.
The error will be a Error 420, Rate Limited. The error code embedded in either JSON or XML structures will be "33" and the accompanying message: "Over the limit for this type of request, please wait a while and try again"
On Tue, Oct 5, 2010 at 1:56 AM, James Peter <zemaj....@gmail.com> wrote: > Hi folks,
> Our service has been down for over 3 days now due to broken API calls.
> Still waiting on any information from Twitter about what's going on, > but still in the dark.
> About 3 days ago we started receiving messages (incorrectly in the new > error structure) saying "Over the limit for this type of request, > please wait a while and try again" with error code 33 when calling > friendships/destroy. According to the API docs, this call is not rate > limited http://dev.twitter.com/doc/post/friendships/destroy All our > API requests are authenticated with the requesting user.
> This happens after about 100 calls. It makes our app completely > unusable. I'm guessing it's a bug, but after 3 days I'm wondering if > anyone else is seeing this problem. As the errors are returned in the > new error structure they didn't appear in our logs at first, so you > might be experiencing this problem and not noticing. The new error > structure returns a set of error messages under "errors" instead of > just a string under "error".
> Due to potential abuse, we've begun locking down bulk deletions that were
> previously unbound. These lack of limits lead to many application
> suspensions and blacklisting as the lack of a rate limit was often
> interpreted as "give us all you've got, non stop," in addition to obvious
> system gaming.
> We're unfortunately not yet publishing the limits on these kinds of actions.
> Though this limit is trickle-down reflected in the API, it's actually a
> site-wide construct. It's an IP-based limit, and not a user-based limit.
> As you'll most likely be able to discover the limits yourself, I'll work on
> getting these numbers released and hopefully get an X-FeatureRateLimit set
> of HTTP headers attached to these requests also.
> I would recommend developing the following strategy when you run into this
> error:
> - Back off for 5-6 minutes (stop retrying this specific kind of request)
> - Try the request again.
> - If it succeeds, great, continue until you're limited again (or work on
> ways to never get limited, such as preventing bulk actions in your UI)
> - If it fails again, wait another 2 minutes, retry & repeat.
> I think the current limits are pretty reasonable, and the time window
> refreshes often.
> The error will be a Error 420, Rate Limited. The error code embedded in
> either JSON or XML structures will be "33" and the accompanying message:
> "Over the limit for this type of request, please wait a while and try again"
> Taylor Singletary
> @episod
> On Tue, Oct 5, 2010 at 1:56 AM, James Peter <zemaj....@gmail.com> wrote:
> > Hi folks,
> > Our service has been down for over 3 days now due to broken API calls.
> > Still waiting on any information from Twitter about what's going on,
> > but still in the dark.
> > About 3 days ago we started receiving messages (incorrectly in the new
> > error structure) saying "Over the limit for this type of request,
> > please wait a while and try again" with error code 33 when calling
> > friendships/destroy. According to the API docs, this call is not rate
> > limitedhttp://dev.twitter.com/doc/post/friendships/destroyAll our
> > API requests are authenticated with the requesting user.
> > This happens after about 100 calls. It makes our app completely
> > unusable. I'm guessing it's a bug, but after 3 days I'm wondering if
> > anyone else is seeing this problem. As the errors are returned in the
> > new error structure they didn't appear in our logs at first, so you
> > might be experiencing this problem and not noticing. The new error
> > structure returns a set of error messages under "errors" instead of
> > just a string under "error".
The overview of rate limits on the developer site provides some more background about rate limits in general and then goes onto link to the above document. The overview is published here: http://dev.twitter.com/pages/rate-limiting
On Wed, Oct 6, 2010 at 8:13 AM, Dewald Pretorius <dpr...@gmail.com> wrote: > Are any of the other POST methods now also similarly rate limited, or > is it only destroy friendship?
> On Oct 5, 11:13 am, Taylor Singletary <taylorsinglet...@twitter.com> > wrote: >> Hi James,
>> I'll re-post this in the group thread as well.
>> Due to potential abuse, we've begun locking down bulk deletions that were >> previously unbound. These lack of limits lead to many application >> suspensions and blacklisting as the lack of a rate limit was often >> interpreted as "give us all you've got, non stop," in addition to obvious >> system gaming.
>> We're unfortunately not yet publishing the limits on these kinds of actions. >> Though this limit is trickle-down reflected in the API, it's actually a >> site-wide construct. It's an IP-based limit, and not a user-based limit.
>> As you'll most likely be able to discover the limits yourself, I'll work on >> getting these numbers released and hopefully get an X-FeatureRateLimit set >> of HTTP headers attached to these requests also.
>> I would recommend developing the following strategy when you run into this >> error:
>> - Back off for 5-6 minutes (stop retrying this specific kind of request) >> - Try the request again. >> - If it succeeds, great, continue until you're limited again (or work on >> ways to never get limited, such as preventing bulk actions in your UI) >> - If it fails again, wait another 2 minutes, retry & repeat.
>> I think the current limits are pretty reasonable, and the time window >> refreshes often.
>> The error will be a Error 420, Rate Limited. The error code embedded in >> either JSON or XML structures will be "33" and the accompanying message: >> "Over the limit for this type of request, please wait a while and try again"
>> Taylor Singletary >> @episod
>> On Tue, Oct 5, 2010 at 1:56 AM, James Peter <zemaj....@gmail.com> wrote: >> > Hi folks,
>> > Our service has been down for over 3 days now due to broken API calls.
>> > Still waiting on any information from Twitter about what's going on, >> > but still in the dark.
>> > About 3 days ago we started receiving messages (incorrectly in the new >> > error structure) saying "Over the limit for this type of request, >> > please wait a while and try again" with error code 33 when calling >> > friendships/destroy. According to the API docs, this call is not rate >> > limitedhttp://dev.twitter.com/doc/post/friendships/destroyAll our >> > API requests are authenticated with the requesting user.
>> > This happens after about 100 calls. It makes our app completely >> > unusable. I'm guessing it's a bug, but after 3 days I'm wondering if >> > anyone else is seeing this problem. As the errors are returned in the >> > new error structure they didn't appear in our logs at first, so you >> > might be experiencing this problem and not noticing. The new error >> > structure returns a set of error messages under "errors" instead of >> > just a string under "error".
I'm aware of those rate limits. I was referring to methods that used
to be, "Give us all you got," such as destroy friendship. For example,
create block, destroy block, etc.
On Oct 6, 3:38 pm, Matt Harris <thematthar...@twitter.com> wrote:
> The overview of rate limits on the developer site provides some more
> background about rate limits in general and then goes onto link to the
> above document. The overview is published here:
> http://dev.twitter.com/pages/rate-limiting
> On Wed, Oct 6, 2010 at 8:13 AM, Dewald Pretorius <dpr...@gmail.com> wrote:
> > Are any of the other POST methods now also similarly rate limited, or
> > is it only destroy friendship?
> > On Oct 5, 11:13 am, Taylor Singletary <taylorsinglet...@twitter.com>
> > wrote:
> >> Hi James,
> >> I'll re-post this in the group thread as well.
> >> Due to potential abuse, we've begun locking down bulk deletions that were
> >> previously unbound. These lack of limits lead to many application
> >> suspensions and blacklisting as the lack of a rate limit was often
> >> interpreted as "give us all you've got, non stop," in addition to obvious
> >> system gaming.
> >> We're unfortunately not yet publishing the limits on these kinds of actions.
> >> Though this limit is trickle-down reflected in the API, it's actually a
> >> site-wide construct. It's an IP-based limit, and not a user-based limit.
> >> As you'll most likely be able to discover the limits yourself, I'll work on
> >> getting these numbers released and hopefully get an X-FeatureRateLimit set
> >> of HTTP headers attached to these requests also.
> >> I would recommend developing the following strategy when you run into this
> >> error:
> >> - Back off for 5-6 minutes (stop retrying this specific kind of request)
> >> - Try the request again.
> >> - If it succeeds, great, continue until you're limited again (or work on
> >> ways to never get limited, such as preventing bulk actions in your UI)
> >> - If it fails again, wait another 2 minutes, retry & repeat.
> >> I think the current limits are pretty reasonable, and the time window
> >> refreshes often.
> >> The error will be a Error 420, Rate Limited. The error code embedded in
> >> either JSON or XML structures will be "33" and the accompanying message:
> >> "Over the limit for this type of request, please wait a while and try again"
> >> Taylor Singletary
> >> @episod
> >> On Tue, Oct 5, 2010 at 1:56 AM, James Peter <zemaj....@gmail.com> wrote:
> >> > Hi folks,
> >> > Our service has been down for over 3 days now due to broken API calls.
> >> > Still waiting on any information from Twitter about what's going on,
> >> > but still in the dark.
> >> > About 3 days ago we started receiving messages (incorrectly in the new
> >> > error structure) saying "Over the limit for this type of request,
> >> > please wait a while and try again" with error code 33 when calling
> >> > friendships/destroy. According to the API docs, this call is not rate
> >> > limitedhttp://dev.twitter.com/doc/post/friendships/destroyAllour > >> > API requests are authenticated with the requesting user.
> >> > This happens after about 100 calls. It makes our app completely
> >> > unusable. I'm guessing it's a bug, but after 3 days I'm wondering if
> >> > anyone else is seeing this problem. As the errors are returned in the
> >> > new error structure they didn't appear in our logs at first, so you
> >> > might be experiencing this problem and not noticing. The new error
> >> > structure returns a set of error messages under "errors" instead of
> >> > just a string under "error".
