Rate Limits

Rate limits apply at two levels: a short-window per-minute limiter on every request, and a per-day quota that 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-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	500
Team	1,000
Growth	10,000
Pro	50,000
Enterprise	Unlimited by default; custom caps available

These are the published allowances, not yet an actively enforced daily cap — today, the per-minute limit above is what’s actually gating request volume in real time. This page will drop this caveat once daily enforcement ships.

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.