IP validation places a small real order through your broker and immediately reverses it. It is the only way to prove the entire path works before a live strategy depends on it — because every component in that path can look correct and still fail.
Why a test order and not a simple check
A connectivity check only proves the broker's server answered. It does not prove your key is accepted, your address is whitelisted, your session is valid, or that an order would actually route.
What the test actually proves
Validation exercises all of it at once:
- Your API key and secret are accepted.
- Your address is on the broker's whitelist.
- Today's session token is valid.
- An order constructed by the platform is accepted by the broker.
- The reverse order also goes through, so you are not left holding anything.
That last item is not a formality. An entry that succeeds and an exit that fails is its own category of problem, and a test that only placed an order would not catch it.
Why it cannot be simulated
The obvious objection is that a simulated order would be cheaper. The problem is that a simulated order does not travel the path being tested. It never leaves the platform, so it proves nothing about your broker's view of your credentials, your address or your session.
Everything that can go wrong here goes wrong on the broker's side, at the moment a real request arrives. A test that stops short of that is testing the wrong half of the system.
What the test order actually looks like
Knowing the shape of it removes the hesitation people have about running something that touches their real account.
The platform constructs the smallest valid order the instrument allows — one lot, a liquid contract, a limit price set to fill immediately. It is sent through exactly the path a live strategy would use: your credentials, your address, today's session, your broker's order endpoint.
The broker responds, and that response is recorded verbatim. If the order was accepted, a reversing order goes out immediately to close the position. The whole sequence takes seconds, and at the end you are flat.
What can go wrong mid-test
The two outcomes that are not simply a pass:
- Entry accepted, reverse rejected. Rare, and the reason the test is worth running — it means something would have left you holding a position you did not intend. Square off manually and investigate before trading.
- Entry rejected. The common case, and harmless. Nothing was opened, so nothing needs closing. Read the error and fix the one thing it names.
Running it
1
Finish the setup first
Credentials added, address whitelisted with the broker, and the broker login done for the day.
2
Open Broker Setup, Network tab
The validation action sits beside your allocated address.
3
Check the balance requirement
The screen checks your broker balance first, because a validation that fails on margin tells you nothing about the IP.
4
Run it and read the result
A pass means the whole path works. A failure carries the broker's own reason rather than a generic message.
How often setups actually fail the first time
Worth saying plainly so a first failure does not read as something being badly wrong: most setups fail validation at least once. The usual culprits, roughly in order:
| Cause | How common | Time to fix |
|---|---|---|
| Broker login not done today | Very common | Under a minute |
| Address pasted with a stray character | Common | A minute |
| Whitelist change not yet propagated | Common | Wait a minute, retry |
| Balance below the test minimum | Occasional | Add funds |
| Wrong address entirely | Occasional | A few minutes |
| API key genuinely wrong | Rare | Re-enter from the broker portal |
The last row is rare, which is exactly why regenerating the key should be a last resort rather than a first reaction. Five of those six causes are resolved without touching your credentials at all.
Reading a failure
| What the broker says | What it usually means | Fix |
|---|---|---|
| Unauthorised / forbidden | The address is not whitelisted, or not the one you think | Re-copy the address and re-whitelist |
| Invalid session / login required | Today's broker login was not completed | Complete the login, then re-run |
| Insufficient funds | Balance too low for even a minimal order | Add funds and re-run |
| Invalid credentials | Key or secret wrong — or the address is wrong | Re-enter credentials, then check the address |
| Order type not permitted | The broker restricts this order type for API flow | Usually a broker-side setting on the API app |
The fourth row is the one that misleads people. Several brokers return a credentials error when the real problem is the source address, which is why the whitelisting guide is worth a second pass before you start regenerating keys you did not need to touch.
How to debug without guessing
A useful rule: change one thing, re-run, and read the error again. Changing the key, the address and the session all at once means a pass tells you nothing about which of them was broken.
Validating after a broker-side change
Brokers occasionally change their API arrangements — a new developer portal, a reissued key, a revised login flow. These changes are announced but easy to miss, and the first symptom is usually a failed order rather than an email you read.
The habit worth building is validating after anything that touches the connection, including changes you did not make. A validation run costs a small round-trip charge and a minute; discovering the problem through a missed entry costs considerably more.
When to re-validate
- After connecting a new broker
- After your dedicated IP changes or is reallocated
- After regenerating your API key or secret
- After any stretch of unexplained order rejections
- Before scaling up size on a strategy that has been running small
- After switching the network you trade from
Validation does not need repeating daily. The daily broker login does, and the two are easy to confuse — validation proves the setup, the login refreshes the session.
Reading a pass correctly
A green result is narrower than it feels. It proves that at this moment, with this broker, from this address, with today's session, a small order routed and reversed successfully.
Everything in that sentence is a condition. Change the address, the session or the broker and the result no longer applies. That is why re-validation is tied to changes rather than to a schedule.
What a pass does not extend to
It also says nothing about size. A one-lot test and a four-leg strategy at ten lots are different propositions for your margin, and validation does not touch that question at all.
What validation does not prove
It is worth being precise about the limits, because a green result can create false confidence.
- It does not prove you have margin for your actual position. A one-lot test says nothing about a four-leg strategy at size.
- It does not start your bot. Deployed and started are different states.
- It does not prove your strategy is correct. Routing works; whether the order should have been sent is a separate question.
- It does not hold. A pass today says nothing about tomorrow if your address is dynamic.
For the question of whether the strategy itself is sound, paper trading is the tool — it runs the same engine on live prices without sending anything to a broker.
The short version
Validation is the only test that exercises the whole path, which is why it has to place something real.
- It proves key, address, session and routing together
- It places and reverses a small order, so expect normal broker charges
- Keep a small balance available or it fails for the wrong reason
- Run it after any change to broker, address or credentials
- Change one thing at a time between runs, or a pass tells you nothing
A pass is narrower than it feels: it says this worked, now, at this size. It does not say you have margin for your real position, and it does not start your bot.
Frequently asked questions
Square off manually straight away, then investigate. It is rare, and it is precisely the scenario the test exists to surface before a live strategy depends on that path.
No. Spreads are widest at the open, so a test there can fail for reasons that say nothing about your setup. Run it once the market has settled.
It means orders can route. Whether the strategy is any good, and whether you have margin for it at full size, are separate questions validation does not touch.
Yes. A small order is placed and immediately reversed. That is the point — a simulated check would not prove the broker accepts your traffic.
Only the normal broker charges on a small round trip. The position is reversed immediately, so there is no directional exposure left behind.
Because an order rejected for insufficient funds tells you nothing about whether your IP works. The balance check runs first so the result is actually meaningful.
After any change to broker, address or credentials, and whenever orders start failing unexpectedly. It is not a daily task.
Validation proves connectivity and routing. It does not prove you have margin for your actual position size, and it does not start your bot.
No. The whole purpose is to exercise the real path to your broker. Paper trading needs no broker at all, but it also proves nothing about live routing.
Change one variable at a time and re-run. Changing the key, the address and the session together means a pass will not tell you which of them was the problem.
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.
