Docs / Shared / Rate limits & quotas
Rate limits & quotas
Every response carries your current budget, so a client can back off before it is refused rather than after.
Headers
X-RateLimit-Limit: <your burst> // bucket capacity, from the table below X-RateLimit-Remaining: 97 // requests left in it right now X-RateLimit-Reset: 1 // seconds until a slot frees up // on a 429 only Retry-After: 1
Limiting is a token bucket, not a fixed window. Your plan's bucket holds a burst of requests and refills continuously at the sustained rate, so X-RateLimit-Remaining counts down out of X-RateLimit-Limit and climbs back on its own — there is no window boundary to line up with, which is why Reset is a countdown to the next free slot rather than a timestamp.
The monthly allowance
X-Quota-Limit: <your monthly> // from the table below, or your own agreed allowance X-Quota-Used: 42 // including this request X-Quota-Remaining: 58 // 0 on the refusal
The two limits are separate and answer different questions: the rate limit is how fast, the allowance is how much. Crossing the allowance is a 429 with quota_exceeded rather than rate_limited, and it carries no Retry-After — waiting does not help, because the allowance resets on the 1st.
One request is one credit, and only a successful one counts. A 4xx or a 5xx spends nothing: a mistyped filter costs a 400 and no allowance, and a request that failed on our side is not one you paid for. limit is capped at 100 on every collection but the few listed below, so the most a credit can buy is knowable in advance, and a few routes spend no credit at all.
Requests are counted per account, not per key — a customer with three keys has one allowance and one bucket between them. If you are polling for changes, first_seen_after is the parameter that decides your bill: a complete daily feed of everything new is a few hundred requests a month, while re-downloading the collection to find them is that many every day.
By plan
| Plan | Monthly | Sustained | Burst |
|---|---|---|---|
| Free | 100 requests | 5 req/s | 10 requests |
| Starter | 3,000 requests | 10 req/s | 20 requests |
| Builder | 15,000 requests | 50 req/s | 100 requests |
| Scale | 100,000 requests | 100 req/s | 200 requests |
Routes that spend no credit
A few routes say which file or release a billed walk was read from, rather than serving data of their own, and charging for them would charge you twice for one answer. They are unmetered: a successful request spends no credit, carries no X-Quota-* headers, and is answered even once the month's allowance is spent. Everything else applies as on any route: a key, a plan that includes the dataset (a 403 otherwise), and the per-second rate limit with its X-RateLimit-* headers.
No route served today is on this list: the three that were belonged to datasets retired on 2026-10-16.
The schema says the same thing machine-readably: an operation on a live dataset in GET /v1/schema with "unmetered": true is on this list, and one without it is metered. A route on this list starting to spend credit would be a breaking change, announced with notice.
Collections that page above 100
A reference collection whose whole set is what its readers need declares its own cap on limit, so the set comes back in one request rather than one credit per 100 rows. The default stays 25, a limit above the collection's cap is a 400 that names the cap, and meta.next is null on a page that held everything — follow it anyway, so a client stays right the day a set outgrows one page. Every other collection, jobs among them, stays at 100.
No collection served today pages above 100: the four that did belonged to datasets retired on 2026-10-16.
Each cap is published as max_page_size on its operation in GET /v1/schema, and each collection's own page says how much headroom its cap leaves. Raising a cap ships any time; lowering one narrows what limit accepts, and is announced with notice.