Rate limits and sizes
Every key has its own limits:
| Limit | Default |
|---|---|
| Requests per minute | 300 |
| Requests per hour | 10000 |
| Write requests (POST, PUT, PATCH, DELETE) per minute | 90 |
| File upload size | 25 MB |
| File read size | 5 MB |
| Active keys per account | 50 |
A bulk upload counts as ONE write request however many files are in it, so the archive upload (POST on /sites/<id>/files/archive) is the way to put a whole built site up - not one file write per file.
Every answer carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (Unix time the minute window ends). Over the limit you get 429 rate_limited with Retry-After (seconds): wait that long and retry. GET /limits returns the limits of the key making the call, and says whether they are the standard ones: overridden is true (with override_scope set to key or account) when support has adjusted them for you.
Need a higher limit?
These limits suit almost every dashboard, script and AI assistant. If your tool genuinely needs more - a large account, a migration, a nightly sync over thousands of sites - ask support, say what you are building and roughly how many calls a minute you need. We can raise the limit on a single key or on the whole account, and it applies to your next call - nothing to change in your code.
Some actions also have the panel's own limits, whatever the key: measuring usage (one per site every few minutes), error logs (20 fetches per 10 minutes per account), access logs (30 per 10 minutes), health re-checks (10 an hour), integrity checks and repairs (12 per 10 minutes per site), admin login links (a few per minute).
Good practice
- Cache what does not change often; use
ETag/If-None-Matchon GET requests: an unchanged answer is304 Not Modifiedwith no body. - Poll jobs every 5-10 seconds, not faster.
- On
503 unavailable(a server did not answer) retry after a short wait.