IP whitelisting tells your broker which internet address is allowed to send orders on your behalf. Requests from anywhere else are refused, no matter how valid your API key is. It takes a few minutes to set up and is the single most common reason a first live deployment fails.
How the check works
When your strategy fires, the order goes to the broker's API endpoint. Before the broker looks at the order, it looks at the source address and compares it against the list registered on your API app. Match, and the order proceeds to the usual margin and risk checks. No match, and it is rejected at the door.
The order never reaches the exchange. It is not queued, not retried, and in most cases not logged anywhere you would naturally look. From your side it simply did not happen.
Why intermittent is worse than broken
This is why the key alone is not enough, and why an address that rotates will fail intermittently rather than cleanly. An intermittent failure is far harder to diagnose than a consistent one, because half your testing will succeed.
What whitelisting protects you from
It is easier to get the setup right when you understand what the control is for, rather than treating it as a hoop.
An API key and secret are strings. They can be copied from a config file, a screenshot, a support chat, or a machine that was compromised. Once copied, they are indistinguishable from the original — nothing about the credentials themselves tells the broker who is holding them.
Why a second factor helps here
The address check adds a second, independent condition that is much harder to steal. An attacker with your key still has to originate traffic from the specific address you registered, which means compromising your network rather than just a file.
Where the setting lives
Every broker calls it something slightly different and buries it somewhere different, but it is always attached to the API app or developer console rather than your normal trading account settings.
| Where to look | What it is usually called |
|---|---|
| The broker's developer or API portal | API app settings |
| Inside the app you created for API access | IP whitelist, allowed IPs, or static IP |
| Sometimes under security settings | Trusted IP addresses |
Per-broker walkthroughs live in the broker guides, which cover the connection flow end to end rather than just this one field.
Errors you will actually see
Brokers rarely say "your IP is wrong" in plain words. The messages that usually mean exactly that:
- Invalid API credentials — when the key is fine and the address is not. This is the most misleading one and sends people off regenerating keys.
- Unauthorised access or a bare 403.
- Access denied for this application.
- An order that is accepted by the platform but never appears in your broker's order book.
Telling it apart from a token problem
Both an unregistered address and an expired session produce authorisation-flavoured errors. The way to tell them apart is the wording: a session problem usually names the session or login explicitly, while an address problem usually says unauthorised or forbidden without mentioning a session.
Verify before you trade
Do not let a live signal be the test. Validating puts a tiny order through and reverses it immediately, which exercises the whole path: key, address, token and order routing.
1
Confirm the exact address
Copy it from the Network tab under Broker Setup. A single wrong digit fails the same way as no entry at all.
2
Paste it into the broker's API app
Exactly as shown, with no spaces or trailing characters. Watch for an auto-inserted space when pasting on mobile.
3
Save and allow a moment to propagate
Some brokers take a minute or two for the change to take effect. A failure in the first thirty seconds is not conclusive.
4
Run validation
From Broker Setup, run the IP validation. It places a small test order and reverses it.
5
Read the result
A pass means the whole path works. A fail usually names the broker's own reason, which tells you whether it is the address, the token or the balance.
What to do the first time it fails
Whitelisting failures are common and almost always resolvable in minutes, provided you resist the temptation to change several things at once.
- Read the broker error verbatim. Not the platform message — the broker one. The exact wording narrows it immediately.
- Check today first. Did you complete the broker login? That is the single most likely cause and takes seconds to rule out.
- Compare the addresses character by character. Open the platform screen and the broker setting side by side.
- Re-save the whitelist entry even if it looks correct, then wait a minute.
- Re-run validation. Only now, and only after changing one thing.
- If it still fails, do not regenerate your API key. That introduces a second variable into a problem you have not isolated yet.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Whitelisting a dynamic address | Works today, fails silently later | Use an address genuinely reserved for you |
| Pasting with a trailing space | Treated as a different address | Re-copy and check the field |
| Whitelisting your laptop's local IP | Never matches — the broker sees your public address | Use the public address your traffic exits from |
| Assuming one broker's whitelist covers another | Only the configured broker works | Each broker has its own API app and its own list |
| Testing only in paper mode | Proves nothing about live routing | Validate against the live connection |
Local address versus public address
The third row catches more people than it should. The address in your router's admin page or your machine's network settings is a private address on your local network. The broker sees the public address your internet provider routes you through, which is a different number entirely.
A walkthrough of the most common failure
Almost every whitelisting problem follows the same shape, and recognising it saves an afternoon.
- You set everything up and it works. A test order goes through.
- Days or weeks pass with no problems.
- One morning, orders start failing with a credentials or authorisation error.
- You assume the API key is wrong, regenerate it, and re-enter it.
- It still fails, because the key was never the problem.
- The actual cause is that your address changed and the whitelist entry is now stale.
Why step four makes it worse
Step four is the expensive one. Regenerating a key invalidates the old one, so if the key was fine you have now introduced a second problem on top of the first, and you are debugging two things at once.
Keeping it working
- Use an address that is actually reserved for you, not a dynamic one
- Re-validate after changing broker, network or IP
- Check the address first whenever orders start failing suddenly
- Remember the daily broker login is a separate requirement
- Note where the current address is displayed, before you need it
That fourth point is worth repeating, because the symptoms overlap. An expired daily token and a wrong IP both produce rejected orders, and the fixes are completely different. Checking the token first is usually the faster path, because it expires every single day while the address should not change at all.
The short version
Whitelisting is five minutes of setup that prevents an entire category of silent failure.
- The broker checks the source address before it looks at the order
- A credentials error often means the address, not the key
- Use the public address your platform shows, never your router's local one
- Each broker has its own API app and its own list
- Validate after the change rather than waiting for a live signal to test it
If orders start failing on a setup that worked, check the daily session first and the address second. Changing the API key should be your last move, not your first.
Frequently asked questions
No, if you can avoid it. The protection comes from the entry being narrow and specific to you. A broad range technically satisfies the setup while giving away most of the security benefit.
No. It applies to API access only. Logging into your broker's app or website in the normal way is unaffected.
Your platform displays it. Do not use the address shown in your router or your machine's network settings — that is a private local address, and the broker never sees it.
It is a list of internet addresses the broker will accept API orders from. Requests from any other address are rejected, regardless of whether the API key is valid.
It depends on the broker. Some allow several entries, some allow exactly one. Check your broker's API documentation.
Usually immediately, sometimes a minute or two. If a change does not seem to take effect, wait briefly and validate again before assuming it failed.
Most often the address rotated because it was dynamic. The second most common cause is the daily broker token expiring, which is a separate issue with a separate fix.
The opposite. It narrows where orders can come from, so a leaked API key is far less useful to anyone who finds it.
No. Your router shows a private address on your local network. The broker sees the public address your internet provider routes you through. Use the public one, which your platform displays for you.
Yes. Each broker has its own API app with its own allowed-address list. One address can be used across all of them, but it has to be entered in each.
Start with a free 3-day trial
Build a strategy, backtest it and run it on paper — no broker, no IP and no money needed to try it.
