Rate Limits

Rate limits apply at three levels: a short-window per-minute limiter on every request, a rolling-hour quota that scales with your plan, and a per-day quota that also scales with your plan.

Per-minute limit

Every endpoint enforces a request-rate limit on a rolling window (120 requests per minute by default; a small number of expensive endpoints may set a stricter limit). Every response includes headers describing your current standing against it:

Header	Meaning
RateLimit-Limit	The limit for the current window
RateLimit-Remaining	Requests left in the current window
RateLimit-Reset	Unix timestamp when the window resets

If you exceed it, the API responds 429 with error.code: "rate_limited" (retryable: true) and a Retry-After header giving the number of seconds to wait before retrying.

Per-hour quota by plan

Alongside the per-minute limit and the per-day quota below, a rolling one-hour quota also scales with your plan — it exists so a burst can’t spend an entire day’s allowance in one go:

Plan	API requests per hour
Free	No API access
Solo	1,250
Team	4,000
Growth	12,500
Pro	60,000
Enterprise	Unlimited by default; custom caps available

Exceeding your hourly quota returns 429 with error.code: "rate_limited" (retryable: true) and a Retry-After header — since this is a rolling window rather than a fixed daily reset, Retry-After reflects time within the hour rather than time until UTC midnight.

Per-day quota by plan

API access itself requires a paid plan — the Free tier has no API access at all. Above that, daily request volume is scoped to these per-plan allowances:

Plan	API requests per day
Free	No API access
Solo	5,000
Team	15,000
Growth	50,000
Pro	250,000
Enterprise	Unlimited by default; custom caps available

Exceeding your daily quota returns 429 with error.code: "rate_limited" (retryable: true) and a Retry-After header giving the number of seconds until the quota resets at UTC midnight — the same shape as the per-minute and per-hour limits above.

Building for retries correctly

• rate_limited and dependency_not_ready are the two error codes marked retryable: true — back off (respecting Retry-After where present) and retry those. Every other error code means retrying the identical request won’t help until something changes on your end — see Errors.
• Always send an Idempotency-Key on non-GET requests so a retry after a timeout or 429 can never double-apply a write.