Rate limits

Rate limits apply per key, not per account, so a runaway batch job cannot starve a production integration. That isolation only helps if you use it: give each workload its own key, one for the nightly training pipeline, one for the serving backend, one for ad-hoc experiments. See Create an API key.

Reading the headers

Every response reports where you stand against the current window:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 583
X-RateLimit-Reset: 1785312000

• X-RateLimit-Limit is the number of requests the key is allowed in the window.
• X-RateLimit-Remaining is how many are left.
• X-RateLimit-Reset is the Unix timestamp at which the window resets.

Watch X-RateLimit-Remaining in long-running loops and slow down before you hit zero, rather than reacting after the fact.

Handling 429

When you exceed the limit, the API returns 429 Too Many Requests with a Retry-After header giving the wait in seconds. Back off on that value rather than a fixed interval: it reflects when your key actually has budget again, so you resume as early as possible without burning further requests on rejections. The body follows the standard error envelope.

import time
import requests

def get_with_backoff(url, params=None, attempts=5):
    for _ in range(attempts):
        resp = requests.get(
            url,
            headers={'Authorization': f'Bearer {API_KEY}'},
            params=params,
        )
        if resp.status_code != 429:
            return resp
        time.sleep(int(resp.headers.get('Retry-After', '1')))
    return resp

A 429 retry is always safe: the request was rejected before it did anything. For retries after timeouts, where the server may have acted, see Errors and retries.