Skip to main content
Denialbase enforces rate limits at two layers — Cloud Armor at the edge (per-IP) and Rack::Attack at the application (per-user). Both return 429 Too Many Requests when exceeded, with a Retry-After header telling you how long to wait.

Application-level limits (per authenticated user)

Edge limits (per IP)

Response headers

When a rate limit is in effect or hit, we return:

Retry strategy

1

On 429

Sleep for Retry-After seconds, then retry. Don’t ignore the header — ignoring it will get you edge-banned for 5 minutes.
2

On 5xx

Exponential backoff: 500ms, 1s, 2s, 4s, 8s, 16s, 30s cap. Give up after 5–7 attempts.
3

Use idempotency keys for writes

Best practices

  • Cache read responses where appropriate; GET responses include ETag headers for conditional requests (If-None-Match).
  • Batch where batch endpoints exist — a single call to POST /api/v1/documents/bulk is better than 50 serial uploads.
  • Webhook for event notifications rather than polling (see Webhooks).
  • Paginate list endpoints — don’t pull more than you need. Default page size is 25; max is 100.

Higher limits

Enterprise customers with legitimate high-volume workflows (bulk ingestion, clearinghouse batch uploads) can request higher limits via support@denialbase.com. We’re not in the business of rate-limiting paying customers out of core workflows — but we do want to know the shape of your traffic to keep the platform healthy.