Rate Limits

QWED API rate limiting by plan tier. Learn about Free, Pro, and Enterprise quotas, rate limit headers, and how to handle 429 Too Many Requests responses.

API rate limiting and quotas.

Default Limits

Plan	Requests/min	Requests/day	Batch size
Free	60	1,000	10
Pro	600	50,000	50
Enterprise	Unlimited	Unlimited	100

Rate Limit Headers

Every response includes rate limit headers:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1703073600

Header	Description
X-RateLimit-Limit	Max requests per window
X-RateLimit-Remaining	Requests remaining
X-RateLimit-Reset	Unix timestamp of reset

Rate Limit Response

When rate limited, you’ll receive:

{
  "error": {
    "code": "QWED-005",
    "message": "Rate limit exceeded",
    "details": {
      "limit": 60,
      "reset_at": "2024-12-20T12:01:00Z",
      "retry_after": 45
    }
  }
}

HTTP Status: 429 Too Many Requests

Best Practices

1. Implement Exponential Backoff

import time

def verify_with_retry(client, query, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.verify(query)
        except RateLimitError as e:
            wait = min(2 ** attempt, 60)
            time.sleep(wait)
    raise Exception("Max retries exceeded")

2. Use Batch Endpoints

Instead of individual requests:

# ❌ 10 requests
for item in items:
    client.verify(item)

# ✅ 1 request
client.verify_batch(items)

3. Cache Results

import hashlib

cache = {}

def cached_verify(client, query):
    key = hashlib.sha256(query.encode()).hexdigest()
    if key in cache:
        return cache[key]
    result = client.verify(query)
    cache[key] = result
    return result

Per-Endpoint Limits

Some endpoints have specific limits:

Endpoint	Limit
/verify/batch	100 items/request
/verify/consensus	Per-tenant rate limit (same as default plan limits)
/agent/register	10/hour
/attestation/verify	1000/hour

Fail-closed enforcement

When using Redis-backed rate limiting, the rate limiter operates with a fail-closed policy. If the Redis backend encounters an error at runtime, requests are denied rather than allowed through. This ensures that a temporary Redis outage does not silently bypass rate limits.

If Redis is unavailable at startup, an in-memory fallback is used until the service is restarted with a healthy Redis connection.

Enterprise options

For higher limits, contact us for:

• Custom rate limits
• Dedicated infrastructure
• SLA guarantees