vultr-cli: 403 after enabling IP restrictions on the API key

The key is valid, but the caller's IP is not on the key's allowlist. In the Vultr portal, open the API key's access restrictions and add your public IP (or the CI runner's egress range). Until the source IP is listed, every call 403s.

$ vultr-cli account get
{"error": "Forbidden", "status": 403}
(right after enabling IP restrictions on the API key)

Fix

1. Find your public IP as the API sees it:

   curl -s https://api.vultr.com/v2/account -H "your auth header | head -c 200; echo
   curl -s ifconfig.me; echo

   The second command shows the IP to allowlist.

2. In the portal, edit the API key and add that IP (or CIDR range) to its allowlist. Save.

3. Retry:

   vultr-cli account get

   Expected: account details print.

When this applies

• 403s begin immediately after enabling or editing IP restrictions on the key.
• Works from one network (office) but 403s from another (home, CI).

When it does NOT apply

• 401: the key itself is invalid.
• 403 for a sub-user with API disabled: flip the user-level switch instead.
• 403 on some endpoints only: that is scope/permission shaped, not IP shaped.

Compatibility

• vultr-cli against the Vultr API v2.

Why it happens

IP allowlisting is enforced after key validation: valid key plus disallowed source IP equals 403. The failure looks identical to other 403s, but the timing (right after a restriction change) and the network dependence (works here, fails there) give it away.

Edge cases

• CI runners often egress from a pool; allowlist the whole documented egress range or the 403s come back on the next runner.
• NAT gateways: allowlist the gateway's public IP, not the instance's private IP.
• If you cannot pin the IP, remove the allowlist and compensate with short-lived, tightly held keys instead.

Vultr API keys support access-control restrictions including IP allowlisting in the portal; when enabled, requests from non-listed IPs are rejected with 403 even though the key is valid. This is the standard key-hardening feature: the key authenticates (it exists and is well-formed, so no 401) but the request fails the access-control check. The fix is made in the portal where the key's restrictions are managed: add the NAT/gateway public IP of the caller, or the CI runner's egress range. Automation that moves between networks (laptop to office to CI) is the classic trigger.