Yes, Polymarket provides APIs, but the ecosystem is split into distinct layers: public read-only endpoints for market metadata and prices, authenticated endpoints for trading and portfolio management, and on-chain data that can be queried independently. This article explains the architecture, the authentication model, and how to build a reliable integration. It also covers common pitfalls such as geoblocking, documentation mismatches, and the need for resilient RPC infrastructure when interacting with Polygon.
Direct Answer and Scope
Polymarket does have an API. In fact, it exposes multiple API surfaces depending on what you need to do. The public API (often called the Gamma API) provides market metadata, event listings, and price information without authentication. The authenticated API (the CLOB API) handles order placement, cancellation, and portfolio queries, and requires wallet signatures or API credentials. Separately, because Polymarket settles on Polygon, all trades and positions are also visible on-chain and can be queried through general-purpose RPC providers or indexing services.
This guide focuses on the technical architecture and integration workflow. It does not recommend a specific provider for Polymarket's own endpoints, but it does explain how to choose RPC infrastructure for the on-chain components. For concrete endpoint and provider recommendations, use the RPC Assistant.
- Public API: market discovery, order books, prices, and search.
- Authenticated API: trading, order management, and account data.
- On-chain data: trades, positions, and settlements on Polygon.
- Access may be restricted by jurisdiction; check the official documentation for your region.
Assumptions and Prerequisites
Before integrating, you need a clear understanding of your use case. Are you building a read-only dashboard, a trading bot, or an analytics pipeline? Each requires a different combination of API layers and infrastructure. You will also need a Polygon RPC endpoint if you plan to interact with smart contracts directly or verify on-chain state. For production workloads, a dedicated node or a reliable RPC provider is recommended; shared public endpoints are rate-limited and unsuitable for trading.
You should also be familiar with HTTP APIs, JSON, and basic cryptographic signing (EIP-712 for Polymarket's international exchange). For the US-regulated exchange, access requires an application and KYC process, so plan for onboarding time.
- A Polygon RPC URL (e.g., from a provider or your own node).
- An Ethereum-compatible wallet with a private key for signing (never hardcode it).
- API credentials if using the authenticated CLOB API.
- A development environment with curl or a programming language of your choice.
Mental Model: The Three Layers of Polymarket Data
Think of Polymarket's data as three concentric layers. The outermost layer is the public market data API, which is optimized for discovery and display. It answers questions like "what markets exist?" and "what is the current price?" without requiring identity. The middle layer is the trading API, which requires authentication and is stateful: it manages orders, positions, and balances. The innermost layer is the blockchain itself, where every trade and settlement is recorded as an on-chain event. This layer is immutable and auditable but requires an RPC connection to query.
A robust integration often combines layers. For example, a trading bot might use the public API for market discovery, the authenticated API for order placement, and direct RPC calls to verify settlement or monitor wallet activity. Understanding which layer owns which responsibility prevents redundant calls and improves reliability.
Public API: Market Discovery and Pricing
The public API is the simplest entry point. It typically exposes endpoints for listing markets, retrieving order books, and fetching price history. No API key is required, but rate limits apply. The exact base URL and endpoint paths depend on whether you are using the international or US version; always refer to the official documentation for the correct host. The following example uses a placeholder base URL to illustrate the request pattern.
curl -s "https://PUBLIC_API_BASE/markets?limit=5" | jq '.data[] | {question, slug, volume}'Authenticated API: Trading and Portfolio Management
Trading requires authentication. Polymarket's international exchange uses a two-level scheme: Level 1 authentication uses an EIP-712 signature from your wallet to prove ownership, and Level 2 uses API credentials (key, secret, passphrase) to sign each request with HMAC. The US exchange uses a different model with API keys obtained after KYC. In both cases, you must never expose private keys or API secrets in client-side code.
The following Python snippet demonstrates how you might structure a signed request using the requests library and eth_account for signing. It is illustrative and omits error handling for brevity.
import requests, time, hmac, hashlib, base64
from eth_account import Account
from eth_account.messages import encode_typed_data
# Placeholders: replace with your own values
PRIVATE_KEY = "YOUR_PRIVATE_KEY"
API_KEY = "YOUR_API_KEY"
API_SECRET = "YOUR_API_SECRET"
API_PASSPHRASE = "YOUR_PASSPHRASE"
BASE_URL = "https://AUTHENTICATED_API_BASE"
account = Account.from_key(PRIVATE_KEY)
# Example: sign a message to obtain L2 credentials (simplified)
# In practice, follow the official authentication flow.
def sign_request(method, path, body=""):
timestamp = str(int(time.time() * 1000))
message = timestamp + method + path + body
signature = hmac.new(
base64.b64decode(API_SECRET),
message.encode(),
hashlib.sha256
).digest()
return base64.b64encode(signature).decode()
headers = {
"POLY_API_KEY": API_KEY,
"POLY_PASSPHRASE": API_PASSPHRASE,
"POLY_TIMESTAMP": str(int(time.time() * 1000)),
"POLY_SIGNATURE": sign_request("GET", "/orders"),
}
resp = requests.get(f"{BASE_URL}/orders", headers=headers)
print(resp.json())On-Chain Data and RPC Infrastructure
Because Polymarket runs on Polygon, every trade and settlement is an on-chain event. You can query these events directly using a Polygon RPC endpoint. This is useful for building analytics, verifying fills, or monitoring wallet activity without relying on the trading API. However, public RPC endpoints are often rate-limited and may not provide the historical data you need. For production systems, use a dedicated node or a managed RPC service that offers archive data and high throughput.
When selecting an RPC provider, consider request latency, rate limits, archive support, and reliability. OnFinality provides managed RPC endpoints for Polygon and other networks; you can compare plans on the pricing page. For a deeper discussion of RPC architecture, see the guide to RPC endpoints.
- Use
eth_getLogsto query Polymarket contract events. - Filter by contract address and topic to reduce data volume.
- For historical queries, ensure your provider supports archive data.
- Consider WebSocket subscriptions for real-time trade streams.
curl -s -X POST "YOUR_POLYGON_RPC_URL" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "eth_getLogs",
"params": [{
"address": "0xCONTRACT_ADDRESS",
"fromBlock": "0x0",
"toBlock": "latest",
"topics": ["0xEVENT_TOPIC"]
}],
"id": 1
}'Verification Procedure: Testing Your Integration
After setting up your API calls, verify each layer independently. Start with the public API: fetch a list of markets and confirm the response contains expected fields. Then test authentication by calling a read-only authenticated endpoint (such as /orders) and checking for a 200 status. Finally, test on-chain queries by fetching the latest block number and a known event log. Record the latency and success rate for each call.
The following table outlines a simple verification matrix. Run each test three times and note the results in your own environment. Do not rely on invented benchmarks; measure with your actual infrastructure.
- Public API: GET /markets returns 200 and valid JSON.
- Authenticated API: GET /orders with valid headers returns 200.
- RPC: eth_blockNumber returns a recent block height.
- RPC: eth_getLogs for a known contract returns expected events.
Common Pitfalls and Troubleshooting
Developers frequently encounter documentation mismatches, especially with the US API. For example, query parameters may require snake_case instead of camelCase, and active market filters may return stale events. Always validate responses against the official schema and be prepared to adjust field names. Geoblocking is another common issue: the international API may be inaccessible from certain jurisdictions, and the US API requires KYC. If you receive a 403 or 451 status, check your region and account status.
Rate limiting is another challenge. The public API has stricter limits than the authenticated API. Implement exponential backoff and cache responses where possible. For on-chain queries, batch eth_getLogs requests and use a provider with generous limits. If you encounter inconsistent data between the API and on-chain state, remember that the API may be eventually consistent; the blockchain is the source of truth.
- Check parameter casing (snake_case vs camelCase).
- Verify your IP is not geoblocked.
- Handle 429 responses with retries and backoff.
- Use the blockchain to reconcile discrepancies.
Limitations and Tradeoffs
Polymarket's API is powerful but not a general-purpose data warehouse. The public API is designed for market discovery, not for bulk historical analysis. If you need cross-market aggregation or long-term backfills, you may need to index on-chain data yourself or use a third-party indexing service. The authenticated API is stateful and subject to downtime; build fallbacks and idempotent order handling.
On-chain queries offer the most reliable historical record but require more infrastructure. You must manage RPC connections, handle reorgs, and store data efficiently. For high-frequency trading, latency to the RPC endpoint matters; colocating your infrastructure with your provider can help. Ultimately, the right architecture depends on your use case: a dashboard can rely on the public API, while a trading bot needs a combination of authenticated API and dedicated RPC.
Next Steps: Building a Resilient Integration
Start by prototyping with the public API to understand the data model. Then, set up a Polygon RPC endpoint from a provider like OnFinality and test on-chain queries. Once you are comfortable, apply for API credentials and implement the authentication flow. Always separate your read and write paths, and monitor both for errors and latency.
For production deployments, consider using a dedicated node to avoid rate limits and ensure consistent performance. You can explore OnFinality's dedicated node offerings and compare RPC pricing. If you need help choosing an RPC provider for Polygon, the RPC Assistant can provide a short recommendation based on your requirements.
- Prototype with public API and testnet RPC.
- Implement authentication and secure key storage.
- Set up monitoring for API and RPC calls.
- Scale with dedicated infrastructure as volume grows.