Rate limits
Protective limits apply per tenant. Exceeding a request or run-creation limit returns HTTP 429 with a `Retry-After` backoff interval in seconds.
Limits are protective, per tenant, and stated up front: 120 API requests per minute, 10 run creations per minute, plus the monthly run allowance per plan. Exceeding one returns HTTP 429 with a Retry-After interval in seconds.
This page is the contract — the numbers, the response shape, and the polling pattern that keeps integrations inside it.
The ceilings are sized so a well-behaved integration never meets them: status polling at about one request every five seconds and run creation paced with your pipeline sit far below both.
Tiers
- All plans: up to 120 API requests / minute per tenant.
- Run creation: up to 10 new runs / minute per tenant, in addition to the monthly allowance.
- Monthly runs: Free 150, Starter 200, Pro 500; Enterprise is defined by contract.
Request limits and run-creation limits are separate budgets: a burst of status polls spends the first, a burst of new scans spends the second, and the monthly allowance (Free 150, Starter 200, Pro 500; Enterprise by contract) bounds the total.
The per-minute ceilings apply identically to every plan; the plan tier bounds how much you can run in a month, not how fast the API answers. Upgrading changes the allowance, never the pace.
Best practice
- Use `Retry-After` as the minimum backoff interval before retrying.
- Batch polling: 1 request per 5 seconds is enough for run status.
- Poll run status until tenant webhook delivery is available.
Honor Retry-After as a floor, not a suggestion, and poll run status at about one request per five seconds. Until tenant webhook delivery is available, polling is the supported way to observe completion.
When a 429 arrives, treat Retry-After as what it is — the contract: wait that many seconds, resume, and lengthen your polling interval if they keep happening. One 429 is normal; a stream of them means the client is outpacing the stated budget.