Route Your Algo Through a Static IP: Proxy Setup and Verification for Indian Broker APIs

1. Whitelisting Is Not Routing

Whitelisting writes your static IP into your broker’s developer portal. It changes nothing about where your script sends its requests from. If the script runs on your laptop and calls the broker directly, the request leaves from your home or office IP, and the broker rejects it, even though your whitelist is perfect.

That is the single most common reason people say “I whitelisted it and it still fails.” The fix is to send the request through the static IP. A TradeSteady static IP comes with HTTP and SOCKS5 proxy credentials for exactly this: your script talks to the proxy, the proxy talks to the broker, and the broker sees your static IP.

2. Who Makes the Call to Your Broker?

The question that decides everything is simple: which machine sends the order request to the broker? That machine’s outbound IP is the one the broker checks.

Running your script on a laptop and routing it through the proxy is the cheapest, simplest case: no server to rent, patch or monitor. The rest of this guide covers it.

3. Step 1: Prove the Proxy Gives You the IP

Before you touch your broker, check that your proxy really exits from your static IP. Put the proxy credentials from your dashboard into a quick test that asks an IP-echo service what address it sees.

With curl:

curl -x "socks5h://USER:PASS@HOST:PORT" https://api.ipify.org

Or in Python, comparing the direct and proxied results side by side:

# pip install "requests[socks]"
import requests

PROXY = "socks5h://USER:PASS@HOST:PORT"   # from your TradeSteady dashboard
EXPECTED = "YOUR.STATIC.IP"               # the IP shown in your dashboard
proxies = {"http": PROXY, "https": PROXY}

def egress_ip(proxies=None):
    r = requests.get("https://api.ipify.org", proxies=proxies, timeout=10)
    r.raise_for_status()
    return r.text.strip()

print("direct :", egress_ip())            # your own network's IP
print("proxied:", egress_ip(proxies))     # must equal EXPECTED

The proxied line must match the IP in your dashboard exactly. The direct line should be different. If both lines show the same address, your code is not using the proxy.

The socks5h scheme (with the h) makes the proxy resolve hostnames too, so name lookups do not leave from your own network. requests needs the requests[socks] extra for SOCKS.

4. Step 2: Route the Right Calls

Once the test passes, send your broker calls through the same proxy. With requests, a single session does it:

import requests

session = requests.Session()
session.trust_env = False        # ignore proxy environment variables
session.proxies.update(proxies)  # every call on this session uses the static IP

# Use this session for the broker's ORDER calls (and for creating the
# session/token, if your broker ties it to the IP).
resp = session.post(BROKER_ORDER_URL, json=order, headers=auth_headers, timeout=15)

Two points matter here:

• Route the calls that are checked. Brokers generally validate the IP on order placement, modification and cancellation. Kotak Neo documents this explicitly: login, reports, portfolio, market data and websocket calls are not checked. Confirm the same for your broker, and send only what needs the static IP through the proxy. Keep the rest direct if you prefer.
• Check your SDK. If you use a broker’s official library, look for a proxy option or for access to its underlying HTTP session, and set the proxy there. Do not assume it reads proxy environment variables. Print the egress IP from inside your own code path to be sure.

5. Step 3: Create the Session From the Same IP

Some brokers tie your login session to the IP it was created from. Kotak Neo says so on its developer page: order APIs accept requests only from a whitelisted IP with a session created from that same IP. If the session came from a different address you get error 1037 (session IP mismatch), and a non-whitelisted IP returns 100008.

The safe habit, for any broker:

1. Create the token or session through the proxy, so it is born on the static IP.
2. Place orders through the same proxy.
3. After you add or change a whitelisted IP, generate a fresh token. An older one can keep failing.

6. Step 4: A Pre-Market Check

A static IP is meant to be boring, but your setup can still drift: a proxy setting removed in a refactor, a credential rotated, a new machine without the extra installed. Catch it before the first order, not after a missed trade. Add a check that stops the script if the egress IP is wrong:

import sys

def preflight():
    seen = egress_ip(proxies)
    if seen != EXPECTED:
        sys.exit(f"Egress IP is {seen}, expected {EXPECTED}. Not trading.")

preflight()   # run before the first order of the day

Two details make this check honest. It fails closed: if the proxy is down or the IP does not match, the script stops, and it does not quietly fall back to a direct connection. And it runs on the same machine and code path that will place the orders, not on a different laptop.

7. Timeouts: Do Not Resend Blindly

A proxy adds a hop, so give requests a sensible timeout (the examples use 10 to 15 seconds). But a timeout is not a failure. The order may have reached the broker and the reply may simply have been lost.

• Do not resend on a timeout. Check the order book or positions first, then decide.
• Tag orders if your broker supports it. A reference or tag you generate lets you find the order afterwards.
• Treat a proxy error and a broker rejection differently. A proxy authentication error (HTTP 407) or a connection failure means the order was never sent. A broker rejection with an IP error means it was sent from the wrong address.

8. Troubleshooting

For broker-specific error codes and every cause we know of, read “IP Not Whitelisted”: why your broker keeps rejecting API orders.

9. Frequently Asked Questions