Kalshi Geo-Blocking Microsoft Azure Data Centers

Question

Kalshi Geo-Blocking Microsoft Azure Data Centers

jack sumner 20

Deployment Model: 2

Location: eastus

Details: Need advice on how to avoid the issue described below - Kalshi support sucks - hoping the Microsoft Azure community has an idea to help me around Kalshi's incompetence.

Kalshi knee-jerk reacted to Washington state sending a cease and desist order for their citizens to prevent Kalshi 'gambling'. I live in Florida and my Kalshi trading system is hosted in Azure US EAST. The system worked fine until Kalshi implemented their geo-block. It is a bit ridiculous that because Microsoft is headquartered in Washington State, that they block all traffic from any Azure data center in the world.

Does anyone have any ideas to route my traffic another way to avoid the Kalshi block? To be clear, I am not asking for a way to violate the law. I am legally allowed to trade. Kalshi is not very smart with the implementation of their geo-fence.

--- 1. Summary

Every authenticated attempt to place an order via the API returns HTTP 403 with the message: 'Trading is not currently allowed in Washington on markets in Sports, Elections, Politics, Culture, Tech and Science, and Mentions.' — i.e. all trading categories are blocked.

Our account is physically and network-located in Virginia (VA), an allowed jurisdiction. Kalshi's own geolocation endpoint (/v1/location), queried from the same network egress, returns state_iso: 'VA'. The block keys off the city_name string 'Washington' — our egress geolocates to the town of Washington, Virginia ('Little Washington', Rappahannock County, ZIP 22747), a VA town, not Washington State. Kalshi is mis-applying a Washington-State restriction to a Virginia location whose city is named 'Washington.'

Impact: 100% of order placements fail (0 successful placements since 2026-08-20 15:13 UTC). The error recurs continuously — 570 occurrences in a 30-minute window on 2026-08-25 (one per retry, ~every 7 seconds). Account authentication and all read endpoints work; only order placement is blocked.

Verbatim production error (captured live 2026-08-25)

Response 403: {'error':{ 'code':'Trading_is_not_currently_allowed_in_Washington_on_markets_in_Sports,_Elections,_Politics,_Culture,_Tech_and_Science,_and_Mentions.', 'message':'Trading is not currently allowed in Washington on markets in Sports, Elections, Politics, Culture, Tech and Science, and Mentions.' }}

Representative timestamps (UTC), showing the ~7-second retry cadence: 2026-08-25T12:30:45+0000 403 ... not currently allowed in Washington ... 2026-08-25T12:30:52+0000 403 ... not currently allowed in Washington ... 2026-08-25T12:30:59+0000 403 ... not currently allowed in Washington ... 2026-08-25T12:31:06+0000 403 ... not currently allowed in Washington ... 2026-08-25T12:31:21+0000 403 ... (most recent at capture time) count in last 30 min = 570

The contradiction (Kalshi's own systems disagree)

Kalshi's /v1/location says our state is Virginia (allowed). GET https://api.elections.kalshi.com/v1/location from our egress → HTTP 200: {'country_iso':'US','state_iso':'VA','city_name':'Washington','postal_code':'22747'} - state_iso = VA — an allowed jurisdiction. - city_name = 'Washington' — the town of Washington, VA (ZIP 22747), not Washington State. - The /v1/location endpoint returns 200 and does not itself block.

Yet the order-placement path blocks as if the state were WA. The only field that can produce this is the city_name string 'Washington' being matched against a Washington-State restriction list. /v1/location = VA (allowed) vs. order placement = 'Washington' (blocked) — an internal inconsistency within Kalshi's own systems, caused by a city-name / state-name collision.

Reproduction
From an account/egress that Kalshi geolocates to state_iso: VA, city_name: 'Washington', postal_code: 22747: 2. GET /v1/location → 200, {'country_iso':'US','state_iso':'VA','city_name':'Washington','postal_code':'22747'} (no block; allowed VA). 3. Authenticate + read market data + GET /portfolio/balance → all succeed. 4. Submit any order (e.g. an MLB KXMLBGAME market) → HTTP 403, 'Trading is not currently allowed in Washington ...'.

Expected: order accepted (or rejected for a legitimate reason) — the account is in Virginia, an allowed state. Actual: 403 citing Washington, a state the account is not in.

Scope

┌────────────────────────────────────┬───────────────────────────────────────────┐ │ Action │ Result │ ├────────────────────────────────────┼───────────────────────────────────────────┤ │ GET /v1/location │ OK → state_iso: VA │ ├────────────────────────────────────┼───────────────────────────────────────────┤ │ Authentication (API key signature) │ OK │ ├────────────────────────────────────┼───────────────────────────────────────────┤ │ GET /portfolio/balance │ OK │ ├────────────────────────────────────┼───────────────────────────────────────────┤ │ Read market data │ OK │ ├────────────────────────────────────┼───────────────────────────────────────────┤ │ Place order (any category) │ 403 'not currently allowed in Washington' │ └────────────────────────────────────┴───────────────────────────────────────────┘

The failure is isolated to order placement, and spans all categories (Sports, Elections, Politics, Culture, Tech and Science, Mentions) — confirming a blanket jurisdiction block keyed on the 'Washington' city string, not a category-specific rule.

Root cause (hypothesis)

Kalshi's jurisdiction check matches the city_name string ('Washington') against the Washington-State restriction, instead of (or in addition to) the state_iso field. Our egress geolocates to the town of Washington, Virginia (ZIP 22747), so the string 'Washington' collides with the Washington-State ban and the block is mis-applied — even though state_iso is unambiguously VA. In short: 'Washington, VA' is being treated as 'Washington State.'

Requested resolution (in order of preference)
Key the jurisdiction restriction off state_iso, not the city_name string. The town of Washington, VA (state_iso = VA) is not Washington State (state_iso = WA) and should not be blocked. 2. If city-level checks are required, disambiguate by state: only treat city_name = 'Washington' as restricted when state_iso = 'WA'. Whitelisting ZIP 22747 would also resolve this case. 3. Please confirm whether the restriction is keyed on city_name, so we can corroborate.
Technical appendix

Network egress IP (what Kalshi geolocates): 168.62.60.79 (static; Azure NAT gateway, US) - /v1/location (from that egress): {'country_iso':'US','state_iso':'VA','city_name':'Washington','postal_code':'22747'} (HTTP 200) - API host (reads): api.elections.kalshi.com · API host (orders): external-api.kalshi.com (trade-api/v2) - Error (HTTP 403), verbatim code: Trading_is_not_currently_allowed_in_Washington_on_markets_in_Sports,_Elections,_Politics,_Culture,_Tech_and_Science,_and_Mentions. - Onset: 2026-08-20 15:13 UTC. Still reproducing: 2026-08-25 12:31 UTC (570 hits / 30 min). - Successful order placements in that window: 0. - Two concrete blocked attempts on 2026-08-25 (both MLB KXMLBGAME): KXMLBGAME-26AUG251905HOUNYY-HOU (HOU @ NYY) and KXMLBGAME-26AUG251840BOSMIA-MIA (BOS @ MIA). - We operate from Virginia; the geolocation is correct at the state level (VA). The only issue is the city name being 'Washington.'

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Welcome to Microsoft Q&A.

@jack sumner I hope you are doing well,

I understand the issue. However, this is primarily a third-party geolocation problem on Kalshi's side, rather than an Azure VM routing problem.

Azure assigns public IP addresses to Azure regions, but the geographic information associated with an IP address is maintained by external geolocation providers and can sometimes identify an IP with an incorrect city. Microsoft does not provide a mechanism to change how a third-party service geolocates an Azure public IP. Azure Public IP addresses are tied to their Azure region and can't simply be moved to another region. ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/virtual-network-public-ip-address?utm_source=chatgpt.com"Create, change, or delete an Azure public IP address - Azure Virtual Network | Microsoft Learn"))

In your case, the fact that Kalshi's own /v1/location endpoint reports:

state_iso = VA

while the trading API rejects the request based on "Washington" strongly suggests that Kalshi needs to correct how its jurisdiction check interprets the location.

I would recommend:

Provide Kalshi with the /v1/location response showing VA.
Provide the HTTP 403 response and explain the Washington, VA vs. Washington State ambiguity.
Ask Kalshi to correct the geolocation/jurisdiction mapping for the Azure public IP.
Ask whether they have a supported process for correcting or allowlisting an incorrectly classified IP.

From the Azure side, if you're using a NAT Gateway, you can verify that the VM's outbound traffic is actually using the expected NAT public IP. Microsoft provides troubleshooting guidance for cases where a different outbound IP is observed. ([Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/azure/nat-gateway/troubleshoot-nat-connectivity?utm_source=chatgpt.com"Troubleshoot Azure NAT Gateway connectivity problems - Azure NAT Gateway | Microsoft Learn"))

I would not recommend trying to bypass Kalshi's geographic restriction by routing traffic through another location. If Kalshi has incorrectly classified a Virginia IP, the appropriate solution is for Kalshi to correct that classification.

For Azure reference:

Azure NAT Gateway overview https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview

Troubleshoot Azure NAT Gateway connectivity https://learn.microsoft.com/en-us/troubleshoot/azure/nat-gateway/troubleshoot-nat-connectivity

Azure Public IP addresses https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/virtual-network-public-ip-address

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

jack sumner 20 Reputation points

2026-08-26T19:15:59.3166667+00:00

Thank you for your response and 100% agree with your assessment (this is a Kalshi issue). As mentioned in my post, Kalshi support sucks and was looking for ideas around the block (not illegal, just necessary given Kalshi's ability to help me out).

Moving to another hosting provider is a huge effort. I was looking for creative ideas...

Thanks again for your response
Jose Benjamin Solis Nolasco 12,201 Reputation points Volunteer Moderator

2026-08-26T19:26:39.7766667+00:00

@jack sumner is a pleasure, I hope you can find some workaround sometimes is a pain to star over.

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.
jack sumner 20 Reputation points

2026-08-27T11:42:57.03+00:00

What does this mean to you? 6 days trying to get support, I get this back....
jack sumner 20 Reputation points

2026-08-27T13:05:45.64+00:00

Follow-up from support:

I apologize, but we do not offer phone support at this time. There is no manual override or whitelist. The block clears on its own once order requests arrive from an address that resolves to an allowed state.

Here is a suggestion:

The fix is inside Azure — no datacenter migration needed, and moving regions would not reliably resolve this since shared outbound ranges elsewhere can map the same way. Attach a dedicated static public IP (Standard SKU) or a NAT Gateway to your VM in East US and route your API traffic through it; the newer regional prefixes there resolve to Virginia. Before cutting over, you can confirm how the new address resolves on a public IP geolocation lookup.
jack sumner 20 Reputation points

2026-08-27T20:00:55.0133333+00:00

This worked