Thanks for reaching out.
Our servers never see your computer's local address, only the public IP of whatever internet connection you're on. So localhost, 127.0.0.1 and LAN addresses like 192.168.x.x won't do anything. What you want to whitelist is your connection's current public IP — you can find it at
https://whatismyipaddress.com, or with `curl
ifconfig.me`.
To add it: sign in to your Platform API account, go to Generate / View API Keys, and add the address under IP Restrictions.
To confirm an IP block is actually what you're hitting, look for this response:
{ "error": { "code": 21, "message": "Invalid IP address detected: '203.0.113.5'" } }
The message echoes back the IP we actually saw, so you can compare it against what you've whitelisted. If you're seeing invalid_client or a signature error instead, that's a credentials or signing problem rather than an IP one.
The usual snag with home, cafe or tethered connections is that the IP changes, so a single entry stops working a day later. Two options depending on how you're set up:
1. On Premier or Premier Free you can whitelist an IP range in CIDR notation rather than a single address, which absorbs day-to-day changes. Handy for development — though I'd avoid leaving a very broad range in place on a production key, since the restriction is there to limit the damage if credentials ever leak.
2. The pattern we'd generally suggest: run a small backend or proxy with a fixed IP (a cheap cloud VM is plenty), point your local code at that, and whitelist just the one address. It also keeps your client ID and secret off your laptop, which you'll want anyway before you ship.
One thing that won't help: ngrok and similar tunnels. They expose your local machine to incoming traffic, but don't change the outgoing IP your code uses to reach us - which is what we're checking.