Docs/Docs

rate-limits-ip-allowlists

Last updated Jul 23, 2026


title: Rate Limits & IP Allowlists description: Tighten what a leaked key can do beyond read-only — cap request volume per upstream and lock an upstream to specific source IPs. Pro features. group: Concepts order: 4

Rate Limits & IP Allowlists

Read-only blocking stops destructive requests. But a leaked key can still read your entire database via GET. Two per-upstream controls close that gap — both are Pro features.

Per-upstream rate limiting

Set a cap on how many requests an individual upstream may receive per minute, regardless of source IP:

"The billing API gets at most 100 requests/minute."

When the cap is exceeded, the proxy returns 429 upstream_rate_limited (with a Retry-After: 60 header) and records the block in your block logs. The counter resets every minute.

This catches the runaway-reader: a script (or a hallucinating agent) walking your whole dataset one GET at a time. It complements the per-IP flood limiter, which catches a single attacker firing many requests.

Configure it in the dashboard (Upstreams → Edit → "Rate limit (req/min)"), or via the API:

PATCH /api/upstreams/{id}
Content-Type: application/json

{ "rateLimitPerMinute": 100 }

Leave it blank (or null) for unlimited. Valid range is 1–10000 requests/minute.

Per-upstream IP allowlist

Restrict an upstream so only specific source IPs may call it:

"This key can only be used from our office IP and the CI runner."

When a request arrives from an IP not on the list, the proxy returns 403 ip_blocked and logs it. Empty allowlist = allow all (the default).

Configure it in the dashboard (one IP or CIDR per line), or via the API:

PATCH /api/upstreams/{id}
Content-Type: application/json

{ "ipAllowlist": ["203.0.113.5", "10.0.0.0/8"] }

Format

  • Bare IPv4 addresses: 203.0.113.5
  • IPv4 CIDR ranges: 10.0.0.0/8, 192.168.1.0/24
  • One entry per line in the dashboard, or an array in the API.
  • IPv6 is not yet supported — let us know if you need it.

The source IP is read from Cloudflare's CF-Connecting-IP header (the authoritative edge value). X-Forwarded-For is not trusted.

The three levers, together

Each upstream has three independent controls. They compose:

Lever Catches Default
Blocked methods Destructive writes (POST/PUT/PATCH/DELETE) Writes blocked
Rate limit Volume abuse (a leaked key reading everything) Unlimited
IP allowlist Requests from unexpected locations Allow all

Read-only is the floor. Rate limiting and IP allowlists let you raise the ceiling on a per-upstream basis.

Lock down your API keys in 60 seconds.

Free for 14 days. No credit card. Cancel anytime.

Start your free trial