Restrict your API keys to specific IPs with IP allow lists
An API key is a powerful credential: anyone who has it can send on your behalf. Scoped permissions already let you limit what a key can do, and now you can also limit where it can be used from. AhaSend API keys support an IP allow list, so a key only works when the request comes from a source IP you trust.
What it does
The IP allow list restricts which source IP addresses can authenticate with a given API key. If the list is empty (the default), there is no restriction and the key works from anywhere. As soon as you add one or more entries, any request from an IP that is not on the list is rejected.
How it works
- Add individual IPv4 or IPv6 addresses, or CIDR ranges, for example
203.0.113.4,2001:db8::1, or198.51.100.0/24. - An empty list means no restriction.
- Self-lockout protection: if you try to update a key's own allow list to a value that excludes the IP you are calling from, the change is rejected so you cannot accidentally lock yourself out.
- Changing the allow list requires confirming it is you, so a stolen session cannot quietly widen access.
Where to set it
You can manage the allow list in two places:
- In the dashboard, in the IP Allow List section when you create or edit an API key (direct link).
- Via the Management API, using the
ip_allow_listfield on the create and update API-key endpoints (click here to try it out)
Try it
The quickest way to see it in action is the scope-free ping endpoint. From an allowed IP you get a normal response ("message":"pong"):
curl -i https://api.ahasend.com/v2/ping \
-H "Authorization: Bearer aha-sk-your-key"If your source IP is not on the key's allow list, the same call returns error, confirming the restriction is active. You can check the IP you are calling from with curl -s https://api.ipify.org.
{"message":"source IP 1.2.3.4 is not allowed for this API key"}A few best practices
- Use CIDR ranges for blocks of addresses instead of listing them one by one.
- Combine the allow list with scoped permissions: restrict both what the key can do and where it can be used.
- Keep production and testing keys separate, each with its own allow list and sandbox disabled or enabled.
IP allow lists are available now for all APIv2 keys, on every plan, at no extra cost.