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
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
- 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
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"