[ blog · comparison ]11 min read

API di Polymarket vs Kalshi: una guida fianco a fianco per sviluppatori (auth, CLOB, WebSocket, dati storici)

Sarah Choy·Pubblicato il 3 maggio 2026·11 min di lettura

Polymarket e Kalshi eseguono la stessa primitiva — contratti sì/no su un CLOB — attraverso API completamente diverse. Una pretende firme EIP-712 e un wallet su Polygon; l'altra è un endpoint REST con FIX opzionale. Se stai costruendo un agente di previsione, un bot di arbitraggio o un monitor di smart money, ecco la guida fianco a fianco che dovrebbe già esistere.

In breve

• •Polymarket usa ordini firmati con EIP-712 inviati al suo CLOB su Polygon — si applicano l'onboarding del wallet e le commissioni di gas.
• •Kalshi usa auth standard REST + WebSocket (email/password → token), più un gateway FIX opzionale per gli utenti istituzionali.
• •Entrambe espongono book degli ordini, scambi e dati storici, ma lo schema e la semantica di risoluzione differiscono abbastanza da rendere le librerie 'unificate' l'argomento di Show HN più richiesto in questo angolo del tooling cripto/quant.
• •L'arbitraggio tra piattaforme su contratti equivalenti è il pattern di costruzione più comune (oltre 10 bot open-source su GitHub).
• •API Pick Prediction Markets Search racchiude entrambe le piattaforme in un unico endpoint POST per la scoperta di contratti in linguaggio naturale — 50 crediti per chiamata, risultati semantici ordinati per rilevanza.

Perché esiste questo articolo

Se hai passato un po' di tempo a costruire su mercati di previsione, conosci la richiesta canonica: 'voglio interrogare Polymarket e Kalshi dallo stesso script Python e riavere una lista pulita di contratti corrispondenti.' Il thread di commenti di HN su ogni Show HN di mercati di previsione converge inevitabilmente su questo — c'è un pattern ricorrente di post su "CCXT per i mercati di previsione", a indicare che la domanda esiste e che le soluzioni attuali non centrano del tutto il bersaglio.

La difficoltà è reale. Le due piattaforme risolvono la stessa primitiva — contratti binari "sì/no" su un book degli ordini a limite centrale — ma le espongono attraverso API drasticamente diverse. Ecco una visione funzionante da sviluppatore di entrambe, fianco a fianco, con il codice di cui hai davvero bisogno.

Due piattaforme, due architetture

Polymarket

• Catena: Polygon (regolamenti in USDC.e)
• Auth: firma di dati tipizzati EIP-712 con la chiave privata di un wallet; nessun token bearer tradizionale
• Piazzamento ordini: ordine firmato inviato all'API CLOB; il gas è pagato da Polymarket tramite meta-transazioni
• Scoperta dei mercati: l'API Gamma (REST + JSON) per sfogliare i mercati attivi, più un'API CLOB separata per il book degli ordini in tempo reale
• Dati in tempo reale: stream WebSocket per gli aggiornamenti del book degli ordini e gli scambi
• Dati storici: endpoint REST per gli scambi; snapshot giornalieri scaricabili a parte

Kalshi

• Regolamento: USD via ACH e bonifico (richiesta una banca statunitense)
• Auth: email + password → token bearer, OPPURE chiave API (istituzionale)
• Piazzamento ordini: POST REST autenticato standard verso /portfolio/orders
• Scoperta dei mercati: endpoint REST per eventi, mercati e serie; schema pulito
• Dati in tempo reale: WebSocket e FIX (istituzionale) per esecuzioni, book degli ordini, ticker
• Dati storici: endpoint REST per gli scambi; dati di risoluzione e regolamento dei mercati lineari

Fianco a fianco

Codice funzionante: hello-world su ciascuna

Polymarket: elencare i mercati attivi

import requests

# Gamma API — no auth required for browsing
r = requests.get(
    "https://gamma-api.polymarket.com/markets",
    params={"active": "true", "limit": 25, "order": "volume"},
)
markets = r.json()
for m in markets[:5]:
    print(m["question"], "→", m["outcomePrices"])

Polymarket: piazzare un ordine firmato (bozza)

# Full order placement requires py-order-utils + a Polygon wallet
# This is the structural sketch — not runnable without wallet setup
from py_order_utils.builders import OrderBuilder
from py_order_utils.signer import Signer

signer = Signer(private_key="0xYOUR_PRIVATE_KEY")
builder = OrderBuilder(
    exchange_address="0x...",
    chain_id=137,
    signer=signer,
)

order = builder.build_signed_order({
    "maker": signer.address(),
    "tokenId": "...",        # the yes/no token ID for the market
    "makerAmount": "1000000", # USDC.e in atomic units
    "takerAmount": "1500000",
    "side": "BUY",
    "feeRateBps": 0,
    "nonce": 0,
    "expiration": 0,         # 0 = no expiry
})

requests.post(
    "https://clob.polymarket.com/order",
    json={"order": order, "owner": signer.address(), "orderType": "GTC"},
)

Kalshi: accedere e piazzare un ordine a limite

import requests

# Step 1 — login
r = requests.post(
    "https://api.elections.kalshi.com/trade-api/v2/login",
    json={"email": "you@example.com", "password": "..."},
).json()
token = r["token"]
headers = {"Authorization": f"Bearer {token}"}

# Step 2 — list markets in an event
r = requests.get(
    "https://api.elections.kalshi.com/trade-api/v2/markets",
    params={"event_ticker": "POTUS-2028", "limit": 25},
    headers=headers,
).json()
print(r["markets"][:5])

# Step 3 — place a limit buy on the "Yes" side at 60 cents
r = requests.post(
    "https://api.elections.kalshi.com/trade-api/v2/portfolio/orders",
    headers=headers,
    json={
        "ticker": "POTUS-2028-DEM",
        "type": "limit",
        "action": "buy",
        "side": "yes",
        "count": 100,            # 100 contracts
        "yes_price": 60,         # 60 cents
        "client_order_id": "abc123",
    },
)
print(r.json())

API Pick: scoperta in linguaggio naturale su entrambe

import requests

r = requests.post(
    "https://www.apipick.com/api/search/prediction-markets",
    headers={"x-api-key": "pk_yourkey"},
    json={"query": "Federal Reserve rate cuts before end of 2026"},
)
for hit in r.json()["results"][:5]:
    print(hit["title"], "@", hit["venue"], "→", hit["url"])

# Returns ranked matches across Polymarket + Kalshi.
# 50 credits per call (~$0.05), only on HTTP 200.

Tre pattern di produzione che funzionano davvero

1. Il bot di arbitraggio tra piattaforme

Il pattern più comune su GitHub: una whitelist curata di "questo contratto di Polymarket si risolve sullo stesso esito di questo contratto di Kalshi". Il bot osserva entrambi i book, calcola la probabilità implicita e prende una posizione quando lo spread supera una soglia. Esempi: ImMike/polymarket-arbitrage e realfishsam/prediction-market-arbitrage-bot.

La parte difficile è la whitelist. "La Fed taglierà di 25 pb alla riunione di dicembre?" sembra la stessa cosa a un essere umano, ma le fonti di risoluzione e la formulazione esatta differiscono; un abbinatore automatico sbaglia abbastanza spesso da spingere i bot reali a usare mappature curate da esseri umani.

2. Il monitor di smart money

Le balene su Polymarket sono visibili on-chain. Un monitor osserva Polygon alla ricerca di grandi flussi di ordini su mercati specifici, fa emergere le posizioni rilevanti e segnala i movimenti rapidi di prezzo prima che i titoli arrivino alle API di notizie. Abbinalo a News Search per confermare se un movimento apparente è guidato dalle notizie o pura speculazione.

3. Il feed di previsioni per un agente LLM

Portare i prezzi correnti di Polymarket / Kalshi nel contesto di un agente LLM permette al modello di dare risposte fondate sulla probabilità: "i mercati di scommesse attuali implicano una probabilità di ~65% di X". Questo è il caso d'uso di scoperta che API Pick copre — data una domanda in linguaggio naturale dell'agente, restituisce contratti ordinati per rilevanza così che l'agente possa citare il prezzo nella sua risposta.

Insidie comuni (raccolte dai commenti di HN)

• Firma EIP-712 di Polymarket — la firma dell'ordine è deterministica, ma gli errori di tooling sono comuni. Usa py-order-utils invece di crearne una tua. La maggior parte delle perdite iniziali dei bot deriva da discrepanze di firma che l'API rifiuta in silenzio.
• Limiti di frequenza di Kalshi — documentati a 100 req/sec, ma più bassi su alcuni endpoint nei giorni di eventi affollati (notti elettorali, FOMC). Inserisci retry-with-backoff nel tuo client.
• Picchi di gas di Polymarket — il gas di Polygon può schizzare nei giorni di grande volume. Polymarket sovvenziona la maggior parte del piazzamento degli ordini tramite meta-transazioni, ma il regolamento e il prelievo li paga l'utente. Tienine conto nei calcoli di P&L.
• Discrepanze di regolamento — equivalenti apparenti a volte si risolvono in modo diverso. Leggi sempre le clausole sulla fonte di risoluzione di entrambi i contratti prima di fare pair-trading.
• Disconnessioni di WebSocket — entrambe le piattaforme hanno cali di WebSocket di routine. La logica di riconnessione con replay del numero di sequenza è irrinunciabile per qualsiasi bot in produzione.

Scegliere in fretta

Dove sta andando tutto questo

I mercati di previsione stanno ricevendo una quantità insolita di attenzione mainstream in questo momento: volumi più grandi attorno alle elezioni USA, agli eventi del FOMC, allo sport e alle domande sul decollo dell'IA; integrazioni più ampie con i siti di notizie che mostrano le probabilità implicite; e un'ondata di tooling per sviluppatori (Show HN, repo su GitHub) che converge sullo stesso tema — 'qualcuno dovrebbe scrivere CCXT per i mercati di previsione.'

Non crediamo che una libreria di esecuzione unificata in stile CCXT sia la forma giusta. Le differenze in auth, regolamento e regime normativo sono troppo profonde per astrarle in modo pulito senza mentire all'utente. Ma il problema della scoperta — data una domanda in linguaggio naturale, trovare i contratti che già esistono — è risolvibile con la ricerca semantica, ed è ciò che fa API Pick Prediction Markets Search. Trova il contratto; piazza l'ordine sulla piattaforma.

Scritto da

Sarah Choy

CEO, API Pick

Sarah Choy è la CEO di API Pick. Scrive sulla creazione di API pronte per la produzione per agenti IA e flussi di lavoro con LLM.