Rate limits

Requests are limited per organisation, with a per-IP limit underneath as a backstop. The default is 600 requests per minute per org.

Every response tells you where you stand

You don’t need to guess or track counts yourself:

Header	Meaning
RateLimit-Limit	Your org’s ceiling for the window
RateLimit-Remaining	Requests left in the current window
RateLimit-Reset	When the window resets
Retry-After	On a 429 or 503 — how long to wait

RateLimit-Limit and RateLimit-Remaining are on every response, including successful ones, so you can slow down before you hit the wall rather than after.

When you exceed it

You get rate_limited — HTTP 429 — with Retry-After. Honour that value; it’s authoritative.

r = session.get(url, headers=headers, timeout=30)
if r.status_code == 429:
    time.sleep(int(r.headers.get("Retry-After", "5")))
    r = session.get(url, headers=headers, timeout=30)

Staying inside the limit

Use batch endpoints. One batch of 100 records costs one request; 100 individual writes cost 100. This is the single biggest lever.

Select only the properties you need with ?properties=, and page with a sensible size rather than hammering small pages.

Back off exponentially on 429 and 503, and add jitter so retries from parallel workers don’t resynchronise into a thundering herd.

Don’t parallelise hard. The limit is per org, so ten workers share one budget — they don’t each get their own.

503 also carries Retry-After

A service_unavailable is transient and always retryable. One case is worth knowing: if the rate-limit backend itself is unreachable, the API fails closed with reason: "throttle_unavailable" rather than letting traffic through unmetered. Treat it like a 429 and retry.