Headers
Every authenticated response carries:RateLimit-Remaining is approximate and can read higher than the limit, since a
burst holds more than one second’s worth.
Each request can be answered by any of several API servers, and each server
counts your budget on its own. RateLimit-Remaining is the count on the server
that answered, so successive responses can repeat a value or go up, and a burst
can sometimes run past 20 before the first 429. Plan for your RateLimit-Limit
and do not rely on going over it.
Exceeding it
You get a429 with the code RATE_LIMITED and a Retry-After header in
seconds. Wait that long and retry.
Your allowance refills continuously rather than resetting on a boundary, so
Retry-After is the time until your next request can succeed. A refused request
costs you nothing.
A 429 with the same code and header can also come from a budget other than your
own allowance. A few endpoints read live from the venue holding your account, and
those reads are paced against a limit that belongs to the account rather than to
you, and is shared with everyone else using it, including your own other keys.
So a request well inside your allowance can still be refused while that account
is busy. Handle it exactly the same way: wait the Retry-After interval and
retry. Nothing was placed or changed, so the same request is safe to repeat.
A
429 with no JSON body is not your budget: it means we are shedding load
across all customers. Retry with backoff and tell us if it persists.