Rate limits
Per-key API budgets by plan, honest 429s with Retry-After, and the capture-side limits that protect your endpoints.
Two separate surfaces have limits, and they fail in different directions on purpose.
API calls (/api/v1)
Each API key has a fixed-window budget per minute, set by the workspace's plan:
| Plan | API requests / minute / key |
|---|---|
| Solo | 120 |
| Pro | 600 |
| Team | 1,200 |
Over budget, calls answer 429 with a Retry-After header (seconds) and the standard
problem body (code: rate_limited). The window is a minute; a client that
sleeps Retry-After seconds and retries will always recover.
An await call counts as one call regardless of how long it blocks — long-polling is the polite way to wait.
Your current budget is always visible on GET /api/v1/me as
limits.apiRatePerMinute.
Captures (…/hook/{id})
Capture URLs have their own per-endpoint, per-minute rate from the plan (captureRatePerMinute on
/api/v1/me). Over it, senders receive 429 + Retry-After — and every rejected capture is
counted and shown to you on the Usage page, so a throttled sender is never invisible.
Storage never rejects a sender: past the per-endpoint stored-request cap, the oldest requests are
evicted to make room for the newest. Payloads over the plan's size cap are recorded as an oversize
trace (bodyTruncated: true) rather than dropped without a word.
Where next?
- Errors — the 429 body shape
- Usage page — live budgets and this month's numbers