Polymarket US vs Offshore API Comparison: Authentication, Settlement & Developer Gotchas (March 2026)

Polymarket Global, Polymarket US, Kalshi, and offshore sportsbooks offer four different API surfaces for agent developers. Polymarket US uses Ed25519 auth and CFTC DCM/DCO rails with a separate SDK (polymarket-us). Global trading now goes through the unified polymarket-client against CLOB/Gamma/Data with pUSD settlement. Kalshi’s March 12 fixed-point migration still matters for bots that never migrated. Offshore books still have no public trading APIs — read-only aggregators only. This guide maps the differences that matter for Layer 3 (Trading).

Four APIs, Four Worlds

If you are building an autonomous betting agent, you are choosing between four API ecosystems that share almost nothing beyond the concept of “bet on outcomes.” Each has different authentication, settlement rails, rate limits, and failure modes.

Here is the architecture at a glance:

┌─────────────────────────────────────────────────────────────────────────┐
│                        AGENT TRADING LAYER                             │
├──────────────────┬──────────────────┬───────────────┬──────────────────┤
│ POLYMARKET       │ POLYMARKET US    │ KALSHI        │ OFFSHORE BOOKS   │
│ GLOBAL           │                  │               │                  │
├──────────────────┼──────────────────┼───────────────┼──────────────────┤
│ clob.polymarket  │ api.polymarket   │ trading-api   │ No direct API    │
│   .com           │   .us            │   .kalshi.com │                  │
├──────────────────┼──────────────────┼───────────────┼──────────────────┤
│ EIP-712 + HMAC   │ Ed25519 keys     │ RSA-PSS       │ N/A              │
├──────────────────┼──────────────────┼───────────────┼──────────────────┤
│ pUSD (Polygon)   │ USD (fiat)       │ USD (fiat)    │ USD/crypto       │
├──────────────────┼──────────────────┼───────────────┼──────────────────┤
│ Permissionless   │ KYC required     │ KYC required  │ Varies           │
├──────────────────┼──────────────────┼───────────────┼──────────────────┤
│ REST + WS        │ REST + WS        │ REST+WS+FIX   │ Read-only via    │
│                  │                  │               │ The Odds API     │
├──────────────────┼──────────────────┼───────────────┼──────────────────┤
│ Not a CFTC DCM   │ CFTC DCM + DCO   │ CFTC DCM      │ Offshore license │
└──────────────────┴──────────────────┴───────────────┴──────────────────┘

For the full picture of how trading APIs fit into the four-layer agent stack (identity, wallet, trading, intelligence), see The Agent Betting Stack Explained.

Polymarket Global vs. Polymarket US — The Split That Breaks Your Code

The single biggest source of developer confusion remains the Polymarket split. There are two separate Polymarket API ecosystems that look similar but are technically incompatible.

Authentication: EIP-712 vs. Ed25519

Polymarket Global uses Ethereum-style EIP-712 typed data signatures for L1 wallet attestation, then HMAC-signed L2 API credentials for private CLOB requests. The current official Python path is the unified SDK polymarket-client (AsyncSecureClient / SecureClient) — not py-clob-client or py-clob-client-v2. See polymarket-client place_limit_order and CLOB V2 + unified SDK migration.

# Polymarket Global — unified SDK (polymarket-client)
import os
from polymarket import AsyncSecureClient

async with await AsyncSecureClient.create(
    private_key=os.environ["POLYMARKET_PRIVATE_KEY"],
) as client:
    # omit wallet for default Deposit Wallet flow
    ...

Polymarket US uses Ed25519 cryptographic key pairs — no Ethereum wallet required. You create an account in the Polymarket US iOS app, complete identity verification (KYC), then generate a Key ID and Secret Key at the developer portal (polymarket.us/developer). Authenticated requests use X-PM-Access-Key, X-PM-Timestamp, and X-PM-Signature. Official US docs still say to email [email protected] if you need help getting set up or need an invite code; they do not publish waitlist queue status or blocked-state lists.

# Polymarket US — Ed25519 authentication (separate package)
# pip install polymarket-us  # incompatible with polymarket-client
import os
from polymarket_us import PolymarketUS

client = PolymarketUS(
    key_id=os.environ["POLYMARKET_KEY_ID"],
    secret_key=os.environ["POLYMARKET_SECRET_KEY"],
)

polymarket-client does not work with Polymarket US. If your agent was built on the Global SDK and you want US market access, you need a second SDK integration (polymarket-us, PyPI 0.1.2, Python >=3.10 as of this cycle).

Settlement: pUSD on Polygon vs. USD fiat

Polymarket Global settles in pUSD (Polymarket USD) — an ERC-20 on Polygon backed by USDC. Day-to-day UX still looks like a balance you fund and trade; pUSD is the collateral layer after the CLOB V2 cutover. Deposits and withdrawals go through the Bridge API (and related wallet flows in the unified SDK).

Polymarket US settles in USD. Retail funding methods documented today are debit card, bank transfer (ACH), and wire transfer — not a self-custodied crypto wallet. Clearing runs under the platform’s CFTC DCO function; partner integrations may involve FCMs/IBs/ISVs, but retail docs describe fiat deposits into your trading balance.

Market Coverage and Fees

Polymarket US lists sports markets (NFL, NBA, NHL, MLB, MLS, CBB, tennis, golf, and more). US docs describe politics, culture, finance, and economics as coming soon. Expect a narrower catalog than Global, especially outside sports.

Do not rely on February 2026 fee framing. Global taker fees are no longer limited to early crypto + NCAAB/Serie A rollouts. Official Global fees (match-time, makers not charged) use:

fee = C × feeRate × p × (1 − p)

Maker rebates are calculated per market (you only compete with makers in the same market). Read fee parameters from market details; see Trading Fees and the Maker Rebates Program.

Polymarket US publishes a separate schedule (Fee Schedule), effective exchange-wide from 12 AM ET, Wednesday July 1, 2026:

• Taker theta 0.06 (max $1.50 at p = $0.50 for a 100-lot)
• Maker rebate theta −0.0125 (applied at fill)
• Tiered taker fee rebates for prior-calendar-month taker volume ($250k+ / $1M+ / $10M+)

Changelog for Global product changes: Predictions Changelog.

What This Means for Agent Developers

If your agent needs to trade in the US under the regulated product, Polymarket US is the path — but it requires a full re-integration, not a config change. If your agent already works with Polymarket Global and you want to add US access, plan for:

1. A separate SDK dependency (polymarket-us) and Ed25519 auth flow
2. A different funding pipeline (fiat debit/ACH/wire vs. on-chain bridge / pUSD)
3. Different market availability (US sports-first today)
4. Separate rate limits and endpoint hosts (api.polymarket.us / gateway.polymarket.us)

For agents that need both, abstract your trading layer behind a common interface. Tools like pmxt (a CCXT-style unified SDK for prediction markets) can help — still treat Global and US as distinct adapters.

Kalshi: The March 2026 Breaking Change

Kalshi is the other CFTC-regulated prediction market, but its API is architecturally different from both Polymarket variants.

The Fixed-Point Migration (March 12, 2026)

The biggest Kalshi API change that still breaks old bots: legacy integer count fields and integer cents price fields were removed on March 12, 2026. If your bot was still reading yes_bid (integer cents) instead of yes_bid_dollars, it broke.

This was the culmination of a months-long deprecation cycle. The _fp (fixed-point) equivalents for count fields and _dollars equivalents for price fields were available since late 2025. The deadline was pushed back multiple times — first to February 26, then to March 12. If you missed it, the fix is straightforward:

# BROKEN after March 12, 2026:
price = market["yes_bid"]           # Integer cents — removed
count = market["yes_ask_size"]      # Integer count — removed

# CORRECT:
price = market["yes_bid_dollars"]   # Dollars as float
count = market["yes_ask_size_fp"]   # Fixed-point count

Fractional Trading Rollout

Starting the week of March 9, 2026, Kalshi rolled out fractional trading per-market. Check the fractional_trading_enabled field on market responses. On fractional-enabled markets, the old integer fields would have been truncated even before removal — another reason to migrate to _fp and _dollars immediately.

Authentication: RSA-PSS

Kalshi uses RSA-PSS key pairs for API authentication. You generate an RSA key pair, register the public key through your account settings, then sign each request with the private key. This is more complex than simple API key/secret schemes but standard for financial APIs.

# Kalshi authentication — RSA-PSS signing
import base64, datetime, hashlib
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding

# Sign: timestamp + method + path
timestamp = str(int(datetime.datetime.now().timestamp() * 1000))
message = f"{timestamp}\n{method}\n{path}"
signature = private_key.sign(
    message.encode(),
    padding.PSS(mgf=padding.MGF1(hashes.SHA256()), salt_length=32),
    hashes.SHA256()
)
headers = {
    "KALSHI-ACCESS-KEY": api_key_id,
    "KALSHI-ACCESS-SIGNATURE": base64.b64encode(signature).decode(),
    "KALSHI-ACCESS-TIMESTAMP": timestamp,
}

Kalshi vs. Polymarket for Agents

Kalshi’s demo environment is a major advantage for agent development. You can test your entire trading pipeline against demo-api.kalshi.co before touching real money. Polymarket Global has no equivalent — you test against production. See our Kalshi API tool entry and the full API reference for endpoint-level details.

Offshore Sportsbooks: The API That Doesn’t Exist

Here is the hard truth for agent developers: offshore sportsbooks do not have public trading APIs. BetOnline, Bovada, BookMaker, BetUS — none of them publish API endpoints for placing bets programmatically.

What You Actually Get: The Odds API

The only programmatic access to offshore sportsbook data comes through third-party aggregators. The Odds API is the most developer-friendly option, providing:

• REST endpoints for pre-match and live odds from 70+ bookmakers
• Coverage of major US sports (NFL, NBA, MLB, NHL, NCAAF, NCAAB) plus soccer, MMA, golf, and more
• American, decimal, and fractional odds formats
• Historical odds snapshots

# The Odds API — read-only odds data
import requests

response = requests.get(
    "https://api.the-odds-api.com/v4/sports/basketball_nba/odds",
    params={
        "apiKey": YOUR_API_KEY,
        "regions": "us",          # us, uk, eu, au
        "markets": "h2h,spreads",
        "oddsFormat": "american",
        "bookmakers": "betonlineag,bovada,mybookieag"
    }
)
games = response.json()

But this is read-only. You can see what BetOnline is offering at -110 on the Lakers spread, but you cannot place that bet through an API. Your agent can identify the opportunity, but execution requires either browser automation (fragile, ToS-violating) or manual human action.

This is the fundamental asymmetry between prediction markets and offshore sportsbooks from an agent perspective. Prediction market APIs are full-stack (read market, place order, manage position, stream updates). Offshore sportsbook access is read-only at best.

For more on accessing offshore sportsbook data and the specific books that matter, see our Offshore Sportsbook hub and the Sportsbook API section.

The Odds Normalization Problem

Even comparing data across platforms is harder than it looks. Prediction markets price outcomes as probabilities (0.00–1.00), while sportsbooks use American odds, decimal odds, or fractional odds.

Prediction market:  "Lakers win" = 0.62  (62% implied probability)
Sportsbook:         "Lakers ML"  = -165  (62.3% implied, but includes vig)

Conversion: American → Implied Probability
  Negative odds: probability = |odds| / (|odds| + 100)
    -165 → 165 / 265 = 62.3%
  Positive odds: probability = 100 / (odds + 100)
    +145 → 100 / 245 = 40.8%

The catch: sportsbook implied probabilities include the vig (house edge), so the two sides always sum to more than 100%. A prediction market’s two sides sum to exactly 100% (ignoring the spread). When your agent compares prices across platforms, it must strip the vig before deciding whether an arbitrage opportunity exists.

See our guide on Offshore Sportsbook Odds Normalization for the formulas and our AgentBets Vig Index for daily vig rankings across major books.

Common Developer Issues

These are the issues we see developers hitting repeatedly.

1. Using Global clients Against Polymarket US Endpoints

Symptom: Authentication failures, 401 responses, cryptic signing errors.

Cause: polymarket-client / legacy py-clob-client* use EIP-712 + HMAC. Polymarket US expects Ed25519 signatures and X-PM-* headers. The SDKs are not interchangeable.

Fix: Use polymarket-us for US endpoints. If you need both, create a wrapper interface:

class PredictionMarketClient:
    """Unified interface for Polymarket Global + US"""
    def __init__(self, global_client=None, us_client=None):
        self.global_client = global_client
        self.us_client = us_client

    def place_order(self, market_id, side, price, size, platform="global"):
        if platform == "us":
            return self.us_client.orders.create(...)
        return self.global_client.place_limit_order(...)

2. Kalshi Bots Breaking on March 12

Symptom: KeyError or None values when reading price or count fields from Kalshi market data.

Cause: Legacy integer fields (yes_bid, no_bid, yes_ask_size, etc.) were removed on March 12, 2026.

Fix: Replace all legacy field references with their _dollars or _fp equivalents. Also check for fractional_trading_enabled on each market if you are doing size calculations.

3. Polymarket Rate Limit Confusion

Symptom: 429 errors that seem inconsistent across different endpoints.

Cause: Polymarket Global enforces per-endpoint Cloudflare IP limits, not one global bucket. General rate limiting is 15,000 requests per 10 seconds. CLOB POST /order allows 5,000 / 10s burst and 120,000 / 10 minutes sustained (not the older 3,500 / 36,000 figures). Separate per-signer token-bucket trading limits also apply (volume tiers). Polymarket US Retail API is 20 requests per second per API key (and per IP for public).

Fix: Implement per-endpoint / per-key rate tracking. See our Polymarket Rate Limits Guide, plus official Rate Limits and CLOB Trading Rate Limits. For US: Retail rate limits.

4. The Odds API Data Gaps for Offshore Props

Symptom: Missing or stale odds for prop markets from offshore books.

Cause: The Odds API focuses on major markets (moneylines, spreads, totals). Prop coverage from offshore books is inconsistent and often delayed. Some books simply don’t expose prop data to aggregators.

Fix: For prop market data, you may need to supplement The Odds API with additional sources. Our Odds Converter tool covers the books and markets where data is reliable.

5. Batch Order Limits on Polymarket

Symptom: Batch order requests failing or only partially executing.

Cause: Polymarket Global batch posts allow 1–15 signed orders per post_orders / POST /orders request. Polymarket US Retail docs document batched create/cancel/modify up to 20 orders per request (gateway rejects the whole batch on request-shape failure).

Fix: Chunk Global batches to ≤15. For US, chunk to ≤20 and observe outcomes on the order stream. Pace requests within each platform’s rate limits.

6. WebSocket Disconnects and Stale Data

Symptom: Agent stops receiving price updates, makes decisions on stale data.

Cause: WebSocket connections drop for various reasons — network issues, server restarts, Cloudflare edge rotation. Without heartbeats and reconnection logic, your agent goes blind.

Fix: Implement exponential backoff reconnection. Build heartbeats yourself in Python/TypeScript clients unless the SDK documents automatic handling. See our WebSocket Streaming Guide for reconnection patterns.

7. Cross-Platform Arbitrage: The Settlement Timing Gap

Symptom: Apparent arbitrage opportunities that lose money after accounting for settlement delays.

Cause: Polymarket Global settles on Polygon (minutes for on-chain settlement). Kalshi settles in USD (withdrawals can take days). Offshore books settle via crypto (hours) or wire (days). An arb that looks profitable at execution can evaporate during the settlement window.

Fix: Factor settlement timing into your P&L calculations. For a complete arbitrage implementation, see our Cross-Market Arbitrage Guide and the Sports Betting Arbitrage Bot Guide.

What This Means for Agent Builders

The prediction market and sports betting API landscape is still fragmented. The Polymarket US/Global split, Kalshi’s fixed-point migration, and the continued absence of offshore sportsbook trading APIs mean that building a multi-platform agent requires more engineering work than a single-venue bot.

The practical recommendation: start with one platform, get it working, then expand. If you need US regulatory compliance, start with Kalshi (better docs, demo environment, stable API) or Polymarket US if you specifically need that product’s markets and can complete iOS KYC + Ed25519 API keys. If you need maximum market coverage and permissionless access, start with Polymarket Global on polymarket-client. If you need sportsbook odds data for intelligence without automated execution, add The Odds API as a read-only feed.

For the complete identity, wallet, and intelligence layers that turn a trading API integration into a full autonomous agent, see our guides on agent identity, agent wallets, and the Intelligence layer.

Related

• polymarket-client place_limit_order — Global order placement on the unified SDK
• CLOB V2 + unified SDK migration — uninstall py-clob-client-v2 → polymarket-client
• Prediction Market API Reference — Polymarket vs Kalshi endpoints side-by-side
• Polymarket Rate Limits Guide — per-endpoint pacing for bots

This guide covers Layer 3 (Trading) of the Agent Betting Stack. Last verified: September 7, 2026 (CYCLE 2026-09-07) against docs.polymarket.com and docs.polymarket.us. Found an error or API change we missed? Let us know on Twitter.

Built a prediction market bot? List it in the AgentBets directory so builders and traders can find it.