Rate limits
Two budgets per key — one for everything, a tighter one for writes.
| Paid (Pro and up) | Trial | |
|---|---|---|
| Requests per minute | 60 | 30 |
| Requests per day | 10,000 | 1,000 |
| Writes per minute | 10 | 5 |
| Writes per day | 500 | 50 |
| In flight at once | 2 | 2 |
Writes spend the second budget on top of the first, because a read loop wastes our time and a write loop rewrites your prices. The trial budget is sized to build an integration against and watch it work — a full catalogue push is one request — not to run on.
The headers#
Every response carries X-RateLimit-Remaining, and a write also carries X-RateLimit-Remaining-Write. Going over returns 429 with Retry-After in seconds. Sleep for that long; do not invent your own backoff on top of it.
HTTP/1.1 429 Too Many RequestsRetry-After: 23X-RateLimit-Remaining: 0{ "meta": { "message": "Rate limit reached. Try again in 23 seconds." }, "errors": { "code": "rate_limited" } }Which budget applies to you#
You do not have to work it out. GET /me reports the budget actually in force for the calling key — per_minute, per_day, write_per_minute, write_per_day and a tier of trial or paid — read from the same place the throttle reads, so they always agree with the X-RateLimit-* headers. Size an importer against those numbers, not against the table above.
Need headroom for a bulk import or a migration? Write to us. A limit raised for a week is a five-minute conversation; an integration built to dodge one is permanent.
Limits that are not rate limits#
Creating a lead also spends the account's lead quota — the same allowance a form lead spends, because a key that could create leads for free would be the way around every limit on the plan. When it is gone the answer is 402 quota_reached, which is not a throttle and must not be retried.
Payload ceilings are their own refusal too: 200 matrices per request, 5,000 prices in a single grid, 50,000 across the request. Over that is a 413 and nothing is written. See importing prices.