📏 Rate Limits

Overview

CyberVault implements rate limiting to ensure platform stability, protect against abuse, and guarantee consistent performance for all clients. Limits are evaluated per API key, per endpoint, and reset using a sliding window algorithm for accurate tracking.

💡 Did you know?

When your application approaches 80% of its limit, we send a Warning header to give you time to adjust request pacing before throttling occurs.

Tier-Based Limits

Rate limits scale with your subscription tier. All limits are applied per API key unless noted otherwise.

Plan	Requests / Minute	Requests / Hour	Burst Allowance	Async Queue Depth
Developer	60	1,000	10 req	50
Professional	300	10,000	50 req	500
Enterprise	2,000	100,000	200 req	Unlimited
Breach Response	Temporary 5x boost activated during active incident response (auto-applied)

Endpoint-Specific Limits

Certain endpoints carry higher computational costs and have stricter limits to prevent resource exhaustion.

Endpoint	Method	Limit / Min	Cost Factor	Notes
`/api/v1/threats/scan`	POST	20	5x	Deep inspection payload analysis
`/api/v1/reports/generate`	POST	5	8x	Heavy aggregation, async recommended
`/api/v1/webhooks`	GET	120	1x	Real-time event polling
`/api/v1/compliance/audit`	GET	10	3x	Requires SOC 2/GDPR scopes

Response Headers

Every API response includes rate limit headers to help you track quota usage programmatically.

HTTP Response HeadersHeaders

X-RateLimit-Limit: 300

X-RateLimit-Remaining: 247

X-RateLimit-Reset: 1709827200

X-RateLimit-Window: sliding_60s

Warning: 299-"Rate Limit" "85% of quota consumed"

X-RateLimit-Limit — Maximum requests allowed in the current window
X-RateLimit-Remaining — Requests left before throttling
X-RateLimit-Reset — Unix timestamp when the window resets
Warning — RFC 7234 warning header when usage exceeds 80%

Handling 429 Too Many Requests

When limits are exceeded, CyberVault returns a 429 status code with a JSON body and a Retry-After header.

429 Response BodyJSON

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Request quota exhausted. Please retry after the specified window.",
    "retry_after": 42,
    "quota_reset_at": "2024-03-15T14:30:00Z"
  }
}
                

⚠️ Retry Best Practice

Always implement exponential backoff with jitter. Do not poll aggressively. If you consistently hit limits, consider upgrading your tier or using our async endpoints.

Optimization & Best Practices

→ Use Webhooks Over Polling
Subscribe to events via /webhooks instead of repeatedly calling status endpoints.
→ Batch Requests
Use the ?ids[]=... parameter where supported to consolidate multiple lookups into single calls.
→ Cache Responses
Leverage ETag and Last-Modified headers. Static threat feeds cache for up to 6 hours.
→ Prefer Async Endpoints
For heavy operations (reports, bulk scans), use async APIs and poll job status instead of blocking requests.
→ Monitor Headers Proactively
Track X-RateLimit-Remaining in your telemetry to alert before throttling occurs.

Frequently Asked Questions

Yes. Enterprise clients can request temporary boosts via the dashboard or by contacting support. We typically approve 2x-5x increases for 24-72 hour windows during migration periods or incident response drills.

Limits are evaluated per API key by default. However, all keys tied to the same organization share a global burst pool. If one key exhausts its limit, others retain their individual quotas unless the global pool is depleted.

Persistent throttling triggers an automated alert to your admin inbox. If your use case legitimately requires higher throughput, we recommend upgrading to the next tier or switching to our dedicated VPC endpoint with isolated capacity.

No. Outbound webhooks pushed to your registered URLs are exempt from rate limiting. However, if your endpoint fails to respond with a 200 within 5 seconds, we retry up to 3 times with exponential backoff.

📏 API & Service Rate Limits