Based on the Rate Limits documentation, for resource-intensive APIs, I’m expecting to see something like the following: X-RateLimit-Category: Resource-intensive X-RateLimit-Type: Daily-limit X-RateLimit-Limit: 30000 X-RateLimit-Remaining: 0 Retry-After: 2020-05-31T00:00:00Z
Error
Instead, I’m seeing the following headers (I’ve only included the relevant ones):
HTTP/1.1 429
X-RateLimit-Category: Resource-intensive
X-RateLimit-Type: QPS
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
Which Endpoint/s?
Additional context
For me to be able to respect the Retry-After time period, I need a Retry-After header. Otherwise, I can only assume that the Queries Per Second (QPS) rate limit type means that I should be able to retry after waiting for a second.
Thanks for raising this with us. We will work on improving the messaging here—have you run into this only on the Dashboards endpoint, specifically? Additionally, are your calls successful upon retrying a few seconds later? You’re correct that QPS should reference such behavior.
It looks like I get exactly 20 requests in and then it starts giving the QPS behavior. Each time I see QPS, I call usleep() for 1.5 seconds. I increased the maximum number of retries for this test to 10 and even 15-20 seconds later, it was still complaining. I believe it’s locking me out for the full minute and counting against my daily maximum, but it’s not showing me those details in the headers.
Thanks for confirming @Jonathan_Champ. I’m working with our team to confirm the expected behavior here and see if we can update our documentation if needed.