IP allowlist
Pin a key to addresses or CIDR ranges. A refusal returns a different code from a bad key, on purpose.
A key can optionally be pinned to a set of IPv4/IPv6 addresses or CIDR ranges. Edit the list at https://developers.wasync.app/keys.
A call from an address that is not on the list is refused with:
{ "error": "ip_not_allowed" }Why it is a different code from invalid_key
403 ip_not_allowed and 401 invalid_key are deliberately distinct, because
the fix is opposite:
| Code | What is wrong | What to do |
|---|---|---|
401 invalid_key | The key is unknown or revoked. | Create a new key. Retrying will never help. |
403 ip_not_allowed | The key is fine; the calling address is not on its list. | Add the address. Do not rotate the key. |
Collapsing the two would send you rotating a perfectly good key while the real problem — a new egress address after a deploy, a container that moved hosts — stays unfixed. Branch on the code, never on the status alone.
You cannot lock yourself out
The allowlist is enforced on API calls. The page where you edit it is authenticated by your account, not by the key, so it stays reachable from any address. There is no state in which a key's own allowlist prevents you from fixing that allowlist.
When it is worth it
An allowlist is most useful when your callers have stable egress: a fixed NAT gateway, a VPC egress IP, an on-premise server. It turns a leaked key into a key that only works from your infrastructure.
It is worth less when your callers are elastic — serverless platforms and CI runners rotate addresses, and a list you have to keep chasing will eventually be widened to something meaningless. In that case, prefer narrow scopes and short-lived deployments of the key.