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-Reset and 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`);
}