Rate Limits
Each API key has its own rolling request limit, tied to your subscription plan.
Current limits
Enterprise keys are limited to a fixed number of requests within a rolling time window. Your exact limit and window depend on your contract — check Rate Limits in the Developer Portal for your live numbers.
Monitoring Data endpoints (monitoring.read) draw on a separate per-key counter from
the diagnostic-tool endpoints, so heavy dashboard-style polling of your monitoring data can't exhaust the quota
your diagnostic calls rely on — or the reverse.
| Per-key bucket | Applies to | Default limit |
|---|---|---|
| Diagnostic tools | Every /v1 endpoint except Monitoring Data |
100,000 / hour |
| Monitoring Data | monitoring.read endpoints — domains, subdomains, incidents, Assistant analyses |
2,000 / hour |
Both windows roll continuously. Contract terms may raise these — the Developer Portal shows your live numbers.
Plan quotas
Separate from the per-key request limits above, each plan has feature quotas. The Public API and webhooks are Enterprise-only; the rest apply across the web app and the API.
| Quota | Anonymous | Free | Pro | Enterprise |
|---|---|---|---|---|
| Monitored domains | — | 1 | 20 | Unlimited |
| Diagnostic tool runs / day | 25 | 25 | 1,000 | Unlimited |
| AI Analyze / Smart Diagnose runs / day | 1 | 3 | Unlimited | Unlimited |
| Paqet Assistant analyses / day (per organization) | — | — | 4 | 20 |
| Webhooks | — | — | — | Included |
| Public API | — | — | — | Included |
Daily quotas reset at 00:00 UTC. The Assistant's daily scheduled pass takes the first increment each day; the remainder is headroom for on-demand re-runs.
Response headers
Every response — successful or not — includes your current standing:
| Header | Meaning |
|---|---|
| X-RateLimit-Limit | Total requests allowed in the current window. |
| X-RateLimit-Remaining | Requests left before you're rate limited. |
| X-RateLimit-Reset | Unix timestamp (seconds) when the window resets. |
Handling 429s
Once the limit is hit, further requests receive:
{
"success": false,
"code": "RATE_LIMIT_EXCEEDED",
"message": "You have exceeded the allowed number of requests. Please try again later."
}
Retry strategy
- Read
X-RateLimit-Resetand wait until that time before retrying — don't guess. - Use exponential backoff with jitter for any automated retry loop, capped at a sane maximum.
- Never retry in a tight loop — that just keeps you rate limited and wastes your own compute.
Best practices
- Cache diagnostic results where the target and check type don't need to be re-run every second.
- Split traffic across multiple scoped keys per integration if you have genuinely independent workloads.
- Monitor Usage for trends before you hit the ceiling, not after.
Example: reading headers
const response = await fetch(url, { headers: { Authorization: `Bearer ${apiKey}` } });
const remaining = response.headers.get("X-RateLimit-Remaining");
const resetAt = response.headers.get("X-RateLimit-Reset");
if (response.status === 429) {
const waitMs = (Number(resetAt) * 1000) - Date.now();
console.log(`Rate limited. Retry in ${Math.max(0, waitMs)}ms`);
}