Why does the Kalshi or Polymarket API work on my laptop but fail on my server?

Because the two machines have different egress IP addresses. Your laptop leaves through a residential ISP connection. Your server leaves through a datacenter ASN owned by AWS, Hetzner, DigitalOcean, or similar. Prediction market APIs inspect the network origin of every connection, and datacenter ranges are rejected independently of whether your account is verified and eligible.

Can I just use a commercial VPN instead of a proxy?

Usually not for long. Most commercial VPNs terminate on datacenter hardware, so the egress IP carries the same datacenter ASN flag that got your server blocked. VPN ranges are also shared by thousands of users and get added to block lists quickly, so a VPN that works today can stop working without any change on your side.

Does routing a bot through a proxy let me trade where I am not eligible?

No, and you should not use it that way. Kalshi is available to US residents only, and Polymarket operates a separate US-regulated venue at polymarket.us for US users. A proxy fixes the case where you are eligible but your server is in the wrong place. It does not create eligibility you do not have, and using it to misrepresent your residency violates both platforms' terms.

Why does DNS leak matter for a trading bot?

With a plain socks5:// prefix, the client resolves the hostname locally and then sends the connection through the proxy. Your resolver still sees the request, and some detection systems correlate resolver location with connection origin. The socks5h:// prefix hands the hostname to the proxy so DNS resolution happens at the exit node, keeping the resolver and the connection origin consistent.

How do I confirm my bot is actually exiting from the right country?

Call an IP echo endpoint through the proxy before you place any orders and log the result. If the returned country does not match the session you opened, stop and fix it before trading. A warmup check is much cheaper than debugging a rejected order during a live market move.

Home/Blog/Prediction Market API Proxy

Automated Trading Guides

Kalshi and Polymarket API Access: Why Your Server Gets Blocked

ProxyBase Team

September 2026 • 8 min read

You generated the key. You read the docs. You ran the request from your laptop and it returned data. Then you deployed to a VPS and the same call started failing with a timeout, a 403, or a connection reset.

Nothing is wrong with your code, and nothing is wrong with your API key. The request that worked and the request that fails differ in exactly one respect: the IP address they leave from.

What actually rejects your request

Kalshi and Polymarket both enforce geographic eligibility at the network layer, on every connection, before your credentials are ever evaluated. That check does not look at who you are. It looks at where the TCP connection came from.

The signal they use is the Autonomous System Number behind your IP. Every IP belongs to an AS, and every AS has an operator and a class. Comcast, Verizon, and Deutsche Telekom are eyeball networks: real people on real home connections. AWS, DigitalOcean, Hetzner, and OVH are hosting networks. That classification is public, commercially maintained, and trivially queryable.

So when your bot calls the exchange from us-east-1, the request arrives carrying a hosting ASN. It gets rejected on that basis alone, whether your account is fully verified or not. This is why the failure looks so arbitrary: you can be perfectly eligible and still be blocked, because eligibility and network origin are separate checks.

Why a commercial VPN does not fix it

The obvious next move is a VPN, and it usually works just long enough to be frustrating. Two things go wrong.

Most commercial VPN providers terminate on rented datacenter hardware. Your traffic leaves their exit node carrying the same hosting ASN flag that got your server blocked in the first place, so you have moved from one flagged network to another.

VPN exit IPs are also shared. Thousands of users cycle through a single address, and some fraction of them are hitting the same sensitive endpoints you are. That pattern is visible from the inside, and provider ranges get added to block lists as a unit. A VPN that works today can fail tomorrow with no change on your end, which is a bad property for infrastructure your trading depends on.

Why you should not fight the country rules

Some guides suggest pointing a proxy at the exchange and ignoring the eligibility rules. Both venues build detection for exactly that pattern, and for good reason.

Kalshi is a CFTC-regulated exchange available to US residents. Polymarket runs a separate regulated US venue at polymarket.us, while the international platform at polymarket.com is not offered to US users. Circumventing those boundaries to trade where you are not eligible violates both platforms’ terms and is exactly the behavior their detection systems are built to catch. Rapid IP churn and datacenter latency profiles are independently detectable, and account suspensions are the documented outcome.

The legitimate problem is different, and it is the one serious bot operators actually have: your server is not where you are. You are eligible, your account is verified, and your infrastructure is in the wrong country: a US-based developer running on a Frankfurt VPS, or a European developer whose bot sits in Virginia. The proxy restores the access you are already entitled to. It does not manufacture entitlement you lack.

Opening a country-matched session

With ProxyBase you do not encode the country into the SOCKS5 username. Country is a parameter of the session you open, and the credentials you get back are tied to a seller node in that country. Here is the full flow, from session creation to an authenticated API call:

import requests

API     = "https://api.proxybase.xyz/v2"
TOKEN   = "sk_your_session_token"   # from POST /v2/auth/verify
GATEWAY = "api.proxybase.xyz:1082"  # v2 buyer SOCKS5 gateway

# 1. Open a sticky session that exits from US residential IPs.
#    Country is chosen here, not in the credential string.
r = requests.post(
    f"{API}/sessions",
    headers={"Authorization": f"Bearer {TOKEN}"},
    json={
        "country": "US",
        "network_type": "residential",
        "session_type": "sticky",
        "spend_cap_microcredits": 5_000_000,
    },
    timeout=15,
)
r.raise_for_status()
session_id = r.json()["session_id"]

# 2. Build the SOCKS5 URL.
#    username = session_id, password = session token.
proxy = f"socks5h://{session_id}:{TOKEN}@{GATEWAY}"
proxies = {"http": proxy, "https": proxy}

# 3. Confirm the exit country BEFORE you trade.
whoami = requests.get(
    "https://api.ipify.org?format=json", proxies=proxies, timeout=10
)
print("exit ip:", whoami.json()["ip"])

# 4. Now call the exchange.
status = requests.get(
    "https://external-api.kalshi.com/trade-api/v2/exchange/status",
    proxies=proxies,
    timeout=10,
)
print(status.json())

Two details in that snippet matter more than they look.

The socks5h:// prefix, rather than socks5://, hands DNS resolution to the proxy. With plain socks5:// your client resolves the hostname locally, so your own resolver still sees every lookup even though the connection itself is proxied. That inconsistency between resolver location and connection origin is a detectable signal, and it is trivial to avoid.

The warmup check in step 3 is not optional. Log your exit IP on every session start and assert on the country. A wrong-country session that you catch at startup costs you one request; the same session discovered mid-trade costs you a rejected order at the worst possible moment.

Sticky versus rotating, for trading specifically

Rotating sessions are the right default for scraping and the wrong default for trading. A trading bot holds authenticated state (you log in, you fetch a book, you place an order) and those calls need to come from a consistent origin. If your IP changes between fetching a price and submitting an order, you look like an account takeover rather than a trader.

Use "session_type": "sticky" and keep one session per venue. If you are hedging across two exchanges, open two sessions rather than sharing one, so that a node failure on one venue cannot take your other leg offline.

WebSocket streams need the same treatment

Both exchanges push market data over WebSocket, and the same network-layer checks apply to the upgrade request. SOCKS5 operates at the transport layer, so a WebSocket client configured with the same proxy URL will tunnel through it. This is the main practical reason to use SOCKS5 rather than an HTTP proxy, which cannot carry a long-lived upgraded connection cleanly.

Keep the stream on the same sticky session as your order flow. Splitting them across two exits is a common mistake: your data feed and your execution path then appear to originate from different networks, which is precisely the pattern detection systems look for.

Frequently Asked Questions

Why does the API work on my laptop but fail on my server?

Different egress IP, different ASN class. Your laptop leaves through a residential ISP; your server leaves through a hosting ASN. The exchange rejects the second one regardless of whether your account is verified.

Can I use a commercial VPN instead?

Rarely for long. Most VPN exits are datacenter-hosted, so they carry the same flag that blocked you, and shared VPN ranges get blocklisted as a unit. Stable infrastructure for a trading bot wants a dedicated residential exit, not a shared consumer VPN.

Does a proxy let me trade where I am not eligible?

No. It fixes being eligible from the wrong location. Kalshi is US-resident only; Polymarket serves US users through polymarket.us. Using a proxy to misrepresent residency breaches both platforms’ terms and is what their detection is designed to catch.

Should I use sticky or rotating sessions?

Sticky for anything authenticated or order-related. Rotating only for unauthenticated data collection. An IP that changes between your price fetch and your order submission reads as account takeover.

How do I verify the exit country?

Call an IP echo endpoint through the proxy at session startup and assert on the country before placing any orders. Log it, so that a future failure can be traced to a bad session rather than guessed at.

Get country-matched residential SOCKS5 credentials in minutes, pay per GB in crypto, no KYC. Open your first session and route your bot through it today.