Polymarket’s geographic restrictions can look confusing because not every restricted location is treated in the same way.
Some jurisdictions are completely blocked.
Others are close-only, meaning existing positions can be reduced or closed but new positions cannot be opened.
There is also a third category that is particularly important for developers and automated traders: jurisdictions where restrictions apply to the Polymarket frontend, while the API itself is not restricted.
That distinction matters if you are building a Polymarket trading bot, market maker, AI agent, arbitrage system, market scanner, or other API-based automation.
According to Polymarket’s current geographic-restriction documentation, restrictions are divided into three major groups. The documentation also specifically tells developers to check geographic eligibility before placing orders and provides a geoblock endpoint that determines whether the requesting IP is blocked.
As of September 2026, Ireland and the Netherlands fall into Polymarket’s “close-only on frontend” category, while the API itself is not restricted from those jurisdictions. This makes locations such as Dublin and Amsterdam technically relevant for authorized API-based infrastructure, particularly because Polymarket’s primary CLOB servers are in AWS eu-west-2, with eu-west-1 identified by Polymarket as the closest non-georestricted region.
That does not mean a trader who is prohibited from using Polymarket can simply move a bot to another country.
VPS location and user eligibility are separate issues.
A VPS should be used to improve the performance and reliability of activity that the trader or developer is already permitted to conduct—not as a method for avoiding legal, account, KYC, sanctions, or geographic restrictions applicable to the user.
With that distinction clear, there is an interesting technical opportunity: eligible API traders can run their Polymarket infrastructure continuously from European data centers close to Polymarket’s primary servers, without depending on a browser, home computer, or residential Internet connection.
This guide explains Polymarket geo restrictions first, then looks at how 24/7 API automation works and why Dublin and Amsterdam are worth considering for compliant API-based Polymarket workloads.
How Polymarket Geo Restrictions Work
Polymarket says geographic restrictions are used for regulatory requirements and compliance with international sanctions. Its documentation tells builders to check the requesting location before trying to place an order because orders from restricted API regions can be rejected.
The important point is that “restricted” does not always mean the same thing.
Polymarket’s current documentation separates jurisdictions into three categories:
| Restriction type | Frontend | API | New positions | Existing positions |
|---|---|---|---|---|
| OFAC / complete block | Blocked | Blocked | No | Cannot close |
| Regulatory close-only | Close-only | Close-only | No | Can close |
| Frontend close-only | Close-only | API not restricted | No new positions via frontend | API availability remains |
For an ordinary web user, the distinction may not seem important.
For an API developer, it is critical.
A location where both frontend and API trading are restricted is fundamentally different from a location where Polymarket itself documents the restriction as applying only to the frontend.
Group 1: Completely Blocked OFAC-Sanctioned Jurisdictions
Polymarket’s strictest category consists of OFAC-sanctioned jurisdictions.
According to the current documentation, these locations are blocked on both the frontend and the API. Users cannot open new positions, and the documentation says existing positions cannot be closed from those jurisdictions either.
The listed jurisdictions include:
| Jurisdiction | Code |
|---|---|
| Iran | IR |
| Syria | SY |
| Cuba | CU |
| North Korea | KP |
| Ukraine — Crimea | UA-43 |
| Ukraine — Donetsk | UA-14 |
| Ukraine — Luhansk | UA-09 |
For API developers, this is the simplest category to interpret.
The source IP should not be expected to place orders through the CLOB from one of these regions.
A bot should detect the restriction before attempting execution and stop the trading workflow rather than repeatedly retrying rejected requests.
Group 2: Regulatory Close-Only Restrictions on Both Frontend and API
The second group is broader.
These jurisdictions are close-only on both the Polymarket frontend and API. According to Polymarket, users can close existing positions but cannot open new ones from these locations.
Current entries include Australia, Belarus, Belgium, Brazil, several Canadian provinces, France, Germany, Italy, New Zealand, Poland, Singapore, Taiwan, Thailand, the United Kingdom, the United States, Venezuela, and a number of other jurisdictions.
The current list includes:
| Jurisdiction | Code |
|---|---|
| Australia | AU |
| Belarus | BY |
| Belgium | BE |
| Burundi | BI |
| Brazil | BR |
| Canada — British Columbia | CA-BC |
| Canada — Ontario | CA-ON |
| Canada — Alberta | CA-AB |
| Canada — Quebec | CA-QC |
| Central African Republic | CF |
| Congo (Kinshasa) | CD |
| Ethiopia | ET |
| France | FR |
| Germany | DE |
| Iraq | IQ |
| Italy | IT |
| Lebanon | LB |
| Libya | LY |
| Myanmar | MM |
| New Zealand | NZ |
| Nicaragua | NI |
| Poland | PL |
| Russia | RU |
| Singapore | SG |
| Slovakia | SK |
| South Sudan | SS |
| Sudan | SD |
| Taiwan | TW |
| Thailand | TH |
| United Kingdom | GB |
| United States | US |
| United States Minor Outlying Islands | UM |
| Venezuela | VE |
| Yemen | YE |
| Zimbabwe | ZW |
Polymarket’s documentation also lists North Korea in this regulatory section, although it separately appears in the stricter OFAC-blocked group. The stricter complete-block treatment should therefore be treated as controlling for that jurisdiction.
For an automation developer, the practical meaning of this group is important:
Moving from the website to the API does not remove the restriction.
If the API itself is close-only, a trading bot should not attempt to create new positions.
This is why an automated system should never assume that “the frontend doesn’t work” automatically means “use the API instead.”
The API restriction status needs to be checked independently.
Group 3: Close-Only on the Frontend, but API Not Restricted
The third category is the most relevant to this article.
Polymarket currently identifies four jurisdictions where the frontend is close-only but the API itself is not restricted:
| Jurisdiction | Code | Frontend | API |
|---|---|---|---|
| Ireland | IE | Close-only | Not restricted |
| Japan | JP | Close-only | Not restricted |
| Malta | MT | Close-only for sports | Not restricted |
| Netherlands | NL | Close-only | Not restricted |
This distinction appears directly in Polymarket’s current developer documentation.
Ireland and the Netherlands therefore create an unusual infrastructure situation.
A user interacting through Polymarket’s standard frontend from those locations may face frontend restrictions, while Polymarket’s documented API policy treats the API separately.
For developers building authorized API-native trading systems, that means Dublin and Amsterdam can be considered as server locations without assuming that frontend behavior defines API availability.
This is especially relevant because these are also major European data-center locations close to Polymarket’s trading infrastructure.
Again, there is an important boundary:
API availability from a server region does not override restrictions applicable to the actual user, account, entity, residency, KYC status, or local law.
The frontend/API distinction should be used to design compliant infrastructure, not to disguise the true location or eligibility of a prohibited trader.
How to Check Whether a Polymarket API Location Is Blocked
Polymarket provides a dedicated geoblock endpoint specifically for developers.
The endpoint checks the IP address making the request and returns information including whether that IP is blocked, the detected country, and the detected region.
Conceptually, a response looks like:
blocked: true or falsealong with the detected country and regional code.
This is extremely useful for automated systems.
A production trading bot should check geographic status during startup rather than simply assuming the VPS location remains eligible forever.
Geo policies can change.
Server IP geolocation databases can change.
A hosting provider can move an IP range.
Polymarket itself can update its restrictions.
A robust system could therefore perform a geoblock check:
when the bot starts, after a server migration, after an IP change, and periodically as part of health monitoring.
If the response indicates that trading is blocked, the order-submission process should stop automatically.
That is better than allowing the strategy to continue generating signals while every execution request fails.
Frontend Access and API Access Are Different Technical Layers
One of the biggest mistakes when discussing Polymarket geo restrictions is treating the website and API as exactly the same service.
They are not.
The frontend is the browser-based interface people use to browse markets, manage positions, and manually trade.
The API is the programmatic infrastructure used by software.
An automated system does not need to behave like someone manually clicking buttons on a website.
Instead, it can use Polymarket’s CLOB API directly.
Polymarket’s current trading infrastructure uses a hybrid Central Limit Order Book. Orders are matched offchain while matched transactions settle through exchange contracts on Polygon. Orders are cryptographically signed, and Polymarket provides official SDK clients for TypeScript, Python, and Rust.
This is what makes genuine API-native automation possible.
The bot can retrieve order books.
It can read prices.
It can calculate spreads.
It can monitor positions.
It can create signed orders.
It can cancel orders.
It can react to fills.
It can maintain market-making quotes.
It can continuously monitor multiple markets without keeping a browser open.
For a serious automated system, the frontend may not be part of the trading path at all.
How Polymarket API Automation Works
A Polymarket automation stack normally consists of several components working together.
The basic workflow looks like:
Market discovery → market data → strategy → risk checks → signed order → CLOB → order monitoring → position management
The market-discovery process identifies markets that meet the strategy’s criteria.
The market-data layer retrieves prices, spreads, and order-book depth.
The strategy decides whether the current price creates a potential opportunity.
The risk engine decides whether the account is allowed to take the proposed exposure.
The execution engine creates and signs an order.
The CLOB receives the order.
The bot then monitors whether that order is live, partially filled, completely filled, rejected, or canceled.
Polymarket’s current CLOB V2 clients handle much of the signing and authentication complexity. The current quickstart provides SDKs for TypeScript, Python, and Rust.
The CLOB has two main authentication levels.
L1 authentication uses an EIP-712 signature from the private key to create or derive API credentials.
L2 authentication uses API credentials and HMAC signing for trading requests such as placing and canceling orders.
That separation is useful for automation because the trading software can authenticate requests consistently without reimplementing the entire signing process for every action.
Why WebSockets Matter for 24/7 Polymarket Bots
An automated Polymarket strategy should generally avoid repeatedly requesting the same market data through REST if live updates are available through WebSockets.
Polymarket provides WebSocket channels for market and user data.
The public market channel can provide live market events and order-book updates.
The authenticated user channel can provide real-time information about a trader’s orders and trades.
This creates a more efficient architecture:
REST API for discovery and occasional state queries
plus
WebSockets for continuous real-time updates
Suppose a bot tracks 200 markets.
Polling every market several times per second would produce a large number of unnecessary API requests.
With WebSockets, the bot can remain subscribed and react when something actually changes.
That reduces API traffic and can also reduce the delay between an event occurring and the strategy seeing it.
Polymarket still imposes API rate limits, including separate limits for general CLOB requests, order-book requests, order placement, cancellations, and other endpoints. Trading endpoints have both burst and sustained limits.
A well-designed system therefore still needs throttling, retry logic, backoff handling, and request accounting.
“Automated” should never mean “send requests as fast as the CPU can generate them.”
What 24/7 API Automation Actually Means
A 24/7 Polymarket bot does not mean every market is always open forever or that Polymarket can never experience maintenance or connectivity issues.
It means the automation infrastructure remains available continuously.
The bot can stay connected while the trader’s personal computer is turned off.
It can monitor markets overnight.
It can react to international news.
It can maintain orders.
It can cancel or replace quotes according to its strategy.
It can track newly filled positions.
It can perform risk checks.
It can log market data.
It can send alerts when something unusual happens.
This persistent operation matters because prediction markets are driven by real-world events that do not wait for normal stock-market hours.
Political announcements can happen overnight.
Election results can arrive at unusual times.
Sports events happen across global time zones.
Crypto markets move continuously.
Geopolitical events can occur at any hour.
Breaking news can change a prediction-market price before a trader at home has even opened a laptop.
For automated strategies, continuous infrastructure can therefore be much more important than continuous human attention.
Heartbeat, Failure Detection and Automated Order Safety
One particularly useful Polymarket feature for bots is the heartbeat endpoint.
Polymarket’s current documentation says heartbeats can be sent to maintain active-session status, and if required heartbeats stop arriving, open orders can be automatically canceled.
This creates a useful fail-safe for automated market-making or continuously quoting strategies.
Imagine a bot has several resting orders open.
Then the application crashes.
Without a heartbeat or another fail-safe, those orders could remain open even though the strategy that manages them is no longer running.
A heartbeat-based approach can reduce that risk.
The server should still have additional monitoring.
A reliable automation stack should track:
the bot process, WebSocket connection, market-data freshness, API response health, database status, available balance, open orders, system CPU, RAM, disk usage, and network connectivity.
Server uptime alone is not enough.
A VPS can remain online while the Python process has stopped.
The Python process can remain alive while the WebSocket is stale.
The WebSocket can be connected while order authentication has failed.
Good 24/7 automation therefore requires both infrastructure uptime and application-level health checks.
Why VPS Location Matters for Polymarket API Trading
For API automation, server location affects part of the network path between the bot and Polymarket’s matching infrastructure.
Polymarket currently states that its primary CLOB servers operate in AWS eu-west-2, the London AWS region. Its documentation specifically identifies eu-west-1 as the closest non-georestricted region.
AWS eu-west-1 is Ireland.
That makes Dublin particularly interesting for Polymarket API infrastructure.
The bot can operate from an Irish data center geographically and network-topologically close to Polymarket’s London-based servers.
Amsterdam is another useful European location to consider because the Netherlands is a major connectivity hub with relatively short routes to London.
Actual latency should always be tested from the specific server to clob.polymarket.com rather than assuming that geography guarantees a particular number.
Routing matters.
Transit providers matter.
Congestion matters.
The source data center matters.
The destination infrastructure can change.
A 10 Gbps port does not automatically produce better API latency than a well-routed 1 Gbps connection.
For most prediction-market bots, the amount of bandwidth is relatively modest. Route quality, packet loss, jitter, stability, and geographic proximity are usually more important than maximum port speed.
Why Dublin Is a Strong Location for Polymarket API Automation
Dublin has one particularly strong advantage: it closely aligns with Polymarket’s own infrastructure guidance.
Polymarket identifies eu-west-1 as its closest non-georestricted region to its primary eu-west-2 servers.
Its current geoblock documentation also places Ireland in the frontend-close-only category while explicitly stating that the API itself is not restricted.
That combination makes Dublin a logical location to evaluate for authorized API-native workloads.
A Dublin VPS can run:
Polymarket market scanners, CLOB V2 clients, Python trading bots, Node.js services, AI agents, WebSocket listeners, market-making systems, databases, alerting applications, pricing models, analytics pipelines, and risk engines.
For a lightweight automation setup, a few CPU cores and 4–8 GB RAM may be sufficient.
For larger multi-market bots, AI workflows, databases, or multiple concurrent strategies, additional CPU and RAM can provide useful headroom.
TradingVPS’s current Dublin plans offer AMD Ryzen 9 9950X CPU resources, DDR5 memory, NVMe SSD storage, dedicated IPv4 addresses, and Windows Server or Ubuntu environments.
For Python, Node.js, Docker, Redis, PostgreSQL, or similar API infrastructure, Ubuntu is generally the simpler operating system choice.
Windows can still make sense when the surrounding software specifically requires it.
Why Amsterdam Also Makes Sense for API-Native Polymarket Trading
Amsterdam is another interesting case because the current Polymarket documentation treats the Netherlands exactly like Ireland for this particular restriction category: close-only on the frontend, while the API itself is not restricted.
That makes Amsterdam relevant to developers whose workflows do not depend on Polymarket’s browser interface.
An API-native application can run directly against Polymarket’s supported trading interfaces while remaining in a major European network hub with comparatively short paths to London.
TradingVPS currently offers Amsterdam configurations with Ryzen 9 9950X CPU resources, DDR5-5200 memory, NVMe storage, dedicated IPv4, and Linux or Windows options.
For API trading, the most important benefits are not simply raw CPU specifications.
A typical Polymarket bot is likely to care more about:
stable connectivity, low network delay, reliable WebSockets, predictable CPU availability, sufficient memory for workers and databases, fast local storage, and continuous server availability.
CPU becomes more important when the strategy performs intensive calculations, parses large amounts of market data, runs many concurrent processes, uses local machine-learning models, generates embeddings, or manages a large number of markets simultaneously.
NVMe can become valuable when the system stores substantial historical order-book data or maintains local databases.
A dedicated IPv4 can also simplify infrastructure management because the bot maintains a consistent source address unless the server is migrated or the IP is changed.
Dublin vs Amsterdam for Polymarket API Trading
Both locations can make sense, but their strengths are slightly different.
| Factor | Dublin | Amsterdam |
|---|---|---|
| Polymarket frontend status | Close-only | Close-only |
| Polymarket API status | Not restricted | Not restricted |
| Proximity to primary CLOB | Excellent | Very good |
| Polymarket infrastructure relevance | eu-west-1 specifically identified by Polymarket | Nearby European connectivity hub |
| Suitable for Python bots | Yes | Yes |
| Suitable for WebSockets | Yes | Yes |
| Suitable for AI agents | Yes | Yes |
| Good for databases/analytics | Yes | Yes |
For pure Polymarket API infrastructure, Dublin has the stronger documentation-based case because Polymarket specifically identifies AWS eu-west-1 as the closest non-georestricted region.
Amsterdam remains a strong alternative for developers who prefer Netherlands-based hosting, network diversity, or other European service dependencies.
Rather than assuming one is always faster, serious traders should benchmark both against the endpoints actually used by their system.
A Practical Architecture for a 24/7 Polymarket API Bot
A production setup does not have to be complicated, but the components should be clearly separated.
A useful architecture might be:
Polymarket WebSocket → Market Data Service → Strategy Engine → Risk Engine → CLOB V2 Execution → Order Monitor → Database → Alerts
The market-data service handles live information.
The strategy determines when an opportunity exists.
The risk engine checks whether that trade fits predefined limits.
The execution engine creates and submits the signed order.
The order monitor tracks whether the order remains live, is partially filled, completely filled, or canceled.
The database stores positions, fills, errors, strategy state, and historical data.
The alerting service notifies the trader if the bot experiences a critical problem.
Separating these responsibilities makes troubleshooting much easier.
If a trade is missed, the developer can determine whether the problem occurred in market data, strategy logic, risk validation, order signing, API connectivity, or exchange response.
How Much VPS Performance Does a Polymarket API Bot Need?
A basic API bot does not normally need enormous computing power.
If it monitors a modest number of markets and performs lightweight calculations, 2 CPU cores and 4–8 GB RAM can be a practical starting point.
For multiple concurrent strategies or a substantial local database, 4 cores and 8–16 GB RAM provide more room.
More complex AI agents, market makers, data collectors, or multi-process environments may justify 4–8 high-performance cores and 16–32 GB RAM.
Local AI inference is a different workload entirely and may require GPU infrastructure.
For ordinary API automation using external AI services, a GPU is generally unnecessary.
The priority should be balance:
fast enough CPU, enough memory, NVMe storage, reliable networking, a dedicated IP, and server monitoring.
Security for 24/7 Polymarket Automation
An API-trading VPS can contain sensitive credentials.
Those may include private keys, Polymarket API credentials, database passwords, alerting tokens, cloud API keys, and strategy code.
They should not be stored casually.
Private keys should never be committed to a public Git repository.
Secrets should be stored through environment variables, restricted configuration files, or a proper secrets-management system.
SSH password authentication can be disabled in favor of key-based access where appropriate.
Unused ports should remain closed.
Server packages should be updated.
A public trading dashboard should not be exposed without authentication.
Logs should also be reviewed carefully.
A poorly written application can accidentally write credentials into an error message, which then ends up permanently stored in a log file.
Automation creates convenience, but it also creates a persistent attack surface.
The same server designed to remain online 24/7 is available to attackers 24/7 as well.
Common Mistakes With Polymarket Geo Restrictions and API Bots
One mistake is assuming all restrictions apply equally to the website and API.
They do not.
Polymarket currently distinguishes complete restrictions, close-only restrictions affecting frontend and API, and frontend-only close restrictions where the API is not restricted.
Another mistake is assuming that running the software from an API-permitted location automatically makes the underlying trader eligible.
It does not.
The geoblock status of the server is one technical control among broader legal, account, sanctions, KYC, and platform requirements.
A third mistake is choosing a VPS purely from an advertised ping number.
Actual API performance depends on the destination, network routing, congestion, application architecture, and response-processing time.
Another common issue is running a bot continuously without a recovery procedure.
A good system should know what to do after:
a VPS reboot, a WebSocket disconnect, an API timeout, a partially filled order, a database restart, a credential failure, or stale market data.
When the application comes back online, it should first retrieve current orders and positions before making new decisions.
Otherwise, it may duplicate exposure because it has forgotten what happened before the restart.
Finally, do not confuse 24/7 automation with guaranteed 24/7 execution.
The server can remain operational around the clock.
The bot can remain available.
But external dependencies can still experience maintenance, degraded service, market closures, API changes, or connectivity problems.
Monitoring and graceful failure handling remain necessary.
Frequently Asked Questions About Polymarket Geo Restrictions and API Automation
Polymarket restricts trading access from certain jurisdictions for regulatory and sanctions-related reasons. Restrictions can apply to the frontend, API, or both.
Polymarket says its primary CLOB servers are in eu-west-2 and identifies eu-west-1, Ireland, as the closest non-georestricted region. Dublin can therefore be a practical location to test for authorized API automation.
Amsterdam is a major European connectivity hub close to London, and the Netherlands is currently frontend close-only while Polymarket’s API is not restricted there. This can make Amsterdam suitable for API-native automation where the developer is otherwise eligible to trade.
Yes. Polymarket publishes separate rate limits for general APIs, CLOB market data, order requests, cancellations, and other operations. Automated systems should implement throttling and error handling.
The heartbeat endpoint allows an automated trading system to signal that it remains active. Polymarket documents automatic cancellation of open orders if required heartbeats stop, providing a useful safety mechanism for unattended automation.
Yes. A properly configured VPS can keep Python, Node.js, WebSocket, database, and monitoring processes running independently of the trader’s home computer, subject to application and external-service availability.
Ubuntu is a practical choice for Python, Node.js, Docker, Redis, PostgreSQL, and other server-side automation technologies. Windows may be preferable if a specific application requires it.
Final Thoughts: Geo Restrictions and 24/7 API Infrastructure Are Separate Questions
Understanding Polymarket geo restrictions starts with recognizing that Polymarket does not apply one universal rule to every jurisdiction.
The current framework has three meaningful levels.
Some locations are completely blocked across the frontend and API.
A larger group is close-only on both the frontend and API.
A third group—including Ireland and the Netherlands—is currently close-only on the frontend while Polymarket explicitly states that the API itself is not restricted.
For developers, that frontend/API distinction is important.
Modern Polymarket automation can operate directly through the CLOB V2 trading stack using Python, TypeScript, or Rust. WebSockets can provide live market and account events. Risk engines can enforce exposure rules. Databases can preserve strategy state. Heartbeats can provide protection for resting orders when an automated process stops responding.
Those components can remain running continuously on a VPS.
Server location then becomes a performance consideration.
Polymarket’s primary CLOB infrastructure is currently located in eu-west-2, while Polymarket itself identifies Ireland’s eu-west-1 as the closest non-georestricted region. That gives Dublin a particularly strong technical case for authorized API-based Polymarket automation.
Amsterdam is another practical European option, particularly for API-native systems, because Polymarket currently lists the Netherlands as frontend close-only while leaving the API unrestricted. Its position as a major European connectivity hub also makes it worth benchmarking against Polymarket’s London-based infrastructure.
TradingVPS provides both Dublin and Amsterdam server options with high-frequency Ryzen CPU resources, DDR5 memory, NVMe storage, dedicated IPv4 addresses, and Windows or Ubuntu environments suitable for Python bots, Node.js services, WebSocket clients, CLOB V2 applications, databases, AI agents, and other persistent automation workloads.
The VPS should still be viewed for what it is:
infrastructure.
It can keep an authorized API trading system online.
It can provide a stable European network location.
It can reduce dependence on home power and residential Internet.
It can help keep WebSocket listeners, trading logic, databases, and monitoring processes available around the clock.
But it does not alter the trader’s legal eligibility or account permissions.
For anyone building serious Polymarket automation, the correct workflow is therefore:
verify eligibility → check geoblock status → choose an appropriate API location → connect through CLOB V2 → use WebSockets → enforce risk controls → monitor continuously.
That creates a much stronger foundation for 24/7 Polymarket API automation than simply running a script on a laptop and hoping the connection stays alive.
This article is provided for general technical and informational purposes only and does not constitute legal, financial, investment, or trading advice. Polymarket restrictions, account requirements, API rules, and applicable laws can change. Always check Polymarket’s current documentation and confirm your own eligibility before using automated trading infrastructure.
