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.

```text
$ 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:
   ```bash
   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:
   ```bash
   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.