IP Allowlists
Pin an API key or OAuth client to a set of source IP ranges (CIDRs). Requests from anywhere else get a 403, even with the correct key.
What it does
An IP allowlist binds a credential to network origin: even a valid key presented from outside the configured CIDR ranges is rejected with forbidden-ip 403. If a key leaks, the thief also needs to originate traffic from inside your network ranges.
- Allowlists are per credential (per API key or OAuth client), not per account — you can pin your production key to your egress IPs while leaving a developer's test key unrestricted.
- The IP check runs before the scope check; a disallowed IP wins even when the scope is also missing.
- The 403 body names the problem type only. It never echoes the caller's IP or your configured ranges — nothing for a prober to learn.
Setting it up
IP allowlists are currently configured by our team — contact support with:
- The key (by name, never send the secret) or OAuth client ID.
- The CIDR ranges to allow, e.g.
203.0.113.0/24, 198.51.100.7/32.
We recommend allowlisting any long-lived tk_live_ key whose egress IPs are stable (most cloud NAT gateways and corporate proxies qualify).
Troubleshooting
Getting forbidden-ip unexpectedly usually means your egress IP changed — a NAT gateway replacement, a new deployment region, or a proxy change. Compare your current egress IP (curl -s https://ifconfig.me from the affected host) with the ranges you registered, and contact support to update them.