Limits and allowances

Current limits. They exist so that one account cannot degrade the service for everyone else, and so the sites we scan — including yours — are never hit harder than they should be.

• 60 requests per minute per key, across all /v1 endpoints.
• 10 scan creations per minute per key, on top of the above. Creating a scan is bounded harder than reading one, because each create launches an outbound render.
• Per account, scan creation (shared by the dashboard and the API): 10 per hour and 20 per day; 50 per hour and 200 per day while the account holds purchased scan credits. These bound how fast an account can scan; the monthly allowance is what bounds how much it spends. They are counted on the account rather than the key, so using a second key, or starting scans from the dashboard at the same time, does not widen them.
• 30 requests per minute per IP, applied before your key is even looked at, so credential guessing is bounded too.
• 3 scans in flight per account. A fourth gets 429 concurrency_limit with Retry-After: 30.
• A deployment-wide concurrency ceiling as well. When the scanner is saturated you get 503 concurrency_limit with Retry-After: 60. Treat it as "come back shortly", not as a failed build.

Always honour Retry-After. Working around the limits — rotating accounts, splitting quota, scripting around the published numbers — is a breach of the Acceptable Use Policy. If your legitimate needs exceed them, talk to us instead.

There are two scan classes, and you choose explicitly with scanClass — it is never inferred from your plan or from the target. They are entitlement classes: they decide which pot pays for the run, and the class is recorded on the scan and echoed in the API response, the allowance headers and the webhook payload.

• quick — the default. The everyday check you run on every deploy.
• evidence — draws on a separate, scarcer allowance, for the runs you want tagged as ones you intend to keep as a dated record of the work.

The two classes draw on separate monthly allowances and separate credit pots. A specific page scan can never spend an evidence credit, and vice versa. Monthly allowance per class, on the plans that include the Scan API:

Allowances reset at the start of each month; the exact moment is in X-Scan-Allowance-Reset and in the resetsAt field of a no_allowance error.

Credits top up one class and are bought as one-time packs from your dashboard. They are spent only after that month's allowance is exhausted, so you never burn a paid credit while free allowance remains, and they stay spendable for 12 months from purchase. Packs are sold for both the quick and evidence classes. The evidence pack costs more per scan and does not buy a different scan — runScan() is never given the class, so the analysis is identical. What it buys is metering: a separate pot and a labelled, dated run. Pack sizes and prices are on the pricing page. The chargedTo field on a create response tells you which pot paid: "allowance" or "credit".

A failed scan is free. It stops counting against the monthly allowance, and a credit spent on it is returned to the pot it came from.

When both pots are empty for a class, creating a scan of that class returns 429 no_allowance, carrying scansUsed, scanLimit, credits and resetsAt.