[ blog · comparison ]11 min read

API Polymarket vs Kalshi : le guide côte à côte du développeur (Auth, CLOB, WebSocket, données historiques)

Sarah Choy·Publié le 3 mai 2026·11 min de lecture

Polymarket et Kalshi font tourner la même primitive — des contrats oui/non sur un CLOB — via des API complètement différentes. L'une réclame des signatures EIP-712 et un wallet Polygon ; l'autre est un endpoint REST avec FIX optionnel. Si vous construisez un agent de prévision, un bot d'arbitrage ou un moniteur de smart money, voici le guide côte à côte qui devrait déjà exister.

L'essentiel

• •Polymarket utilise des ordres signés EIP-712 soumis à son CLOB sur Polygon — onboarding de wallet et frais de gas s'appliquent.
• •Kalshi utilise une auth REST + WebSocket standard (email/mot de passe → token), plus une passerelle FIX optionnelle pour les utilisateurs institutionnels.
• •Les deux exposent carnet d'ordres, trades et données historiques, mais le schéma et la sémantique de résolution diffèrent suffisamment pour que les bibliothèques « unifiées » soient le sujet de Show HN le plus demandé dans ce coin de l'outillage crypto/quant.
• •L'arbitrage inter-places entre contrats équivalents est le pattern de construction le plus courant (10+ bots open-source sur GitHub).
• •API Pick Prediction Markets Search enveloppe les deux places dans un seul endpoint POST pour la découverte de contrats en langage naturel — 50 crédits par appel, résultats sémantiques classés.

Pourquoi cet article existe

Si vous avez passé un peu de temps à construire sur les marchés prédictifs, vous connaissez la demande canonique : « Je veux interroger Polymarket et Kalshi depuis le même script Python et récupérer une liste propre de contrats correspondants. » Le fil de commentaires HN sur chaque Show HN de marché prédictif converge inévitablement là-dessus — il y a un pattern récurrent de posts « CCXT for prediction markets », signe que la demande existe et que les solutions actuelles ne tapent pas tout à fait dans le mille.

La difficulté est réelle. Les deux places résolvent la même primitive — des contrats binaires « oui/non » sur un carnet d'ordres à cours central — mais les exposent via des API radicalement différentes. Voici une vue de développeur qui fonctionne pour les deux, côte à côte, avec le code dont vous avez réellement besoin.

Deux places, deux architectures

Polymarket

• Chaîne : Polygon (règlements en USDC.e)
• Auth : signature de données typées EIP-712 avec une clé privée de wallet ; pas de bearer token traditionnel
• Passage d'ordre : ordre signé soumis à l'API CLOB ; le gas est payé par Polymarket via méta-transactions
• Découverte de marché : API Gamma (REST + JSON) pour parcourir les marchés actifs, plus une API CLOB séparée pour le carnet d'ordres en direct
• Données temps réel : flux WebSocket pour les mises à jour du carnet d'ordres et les trades
• Données historiques : endpoints REST pour les trades ; snapshots quotidiens téléchargeables séparément

Kalshi

• Règlement : USD via ACH et virement (compte bancaire US requis)
• Auth : email + mot de passe → bearer token, OU clé API (institutionnel)
• Passage d'ordre : POST REST authentifié standard vers /portfolio/orders
• Découverte de marché : endpoints REST pour les events, markets et series ; schéma propre
• Données temps réel : WebSocket et FIX (institutionnel) pour les exécutions, le carnet d'ordres, le ticker
• Données historiques : endpoints REST pour les trades ; données de résolution et de règlement de marché simples

Côte à côte

Code qui tourne : hello-world sur chacune

Polymarket : lister les marchés actifs

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 : passer un ordre signé (esquisse)

# 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 : se connecter et passer un ordre 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 : découverte en langage naturel sur les deux

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.

Trois patterns de production qui fonctionnent vraiment

1. Le bot d'arbitrage inter-places

Le pattern le plus courant sur GitHub : une whitelist curée de « ce contrat Polymarket se résout sur la même issue que ce contrat Kalshi ». Le bot surveille les deux carnets, calcule la probabilité implicite et prend une position quand l'écart franchit un seuil. Exemples : ImMike/polymarket-arbitrage et realfishsam/prediction-market-arbitrage-bot.

Le plus dur, c'est la whitelist. « La Fed baissera-t-elle de 25 pb à la réunion de décembre » paraît identique pour un humain, mais les sources de résolution et la formulation exacte diffèrent ; un matcher automatique se trompe assez souvent pour que les vrais bots utilisent des correspondances curées à la main.

2. Le moniteur de smart money

Les whales sur Polymarket sont visibles on-chain. Un moniteur surveille Polygon pour repérer les gros flux d'ordres sur des marchés précis, fait remonter les grosses positions et signale les mouvements de prix rapides avant que les gros titres n'atteignent les API d'actualité. Couplez avec News Search pour confirmer si un mouvement apparent est piloté par l'actualité ou de la pure spéculation.

3. Le flux de prévision pour un agent LLM

Injecter les prix Polymarket / Kalshi du moment dans le contexte d'un agent LLM permet au modèle de donner des réponses ancrées sur des probabilités : « les marchés de paris actuels impliquent une probabilité de ~65 % de X ». C'est le cas d'usage de découverte que couvre API Pick — à partir d'une question en langage naturel de l'agent, renvoyer des contrats classés pour que l'agent puisse citer le prix dans sa réponse.

Pièges courants (compilés à partir des commentaires HN)

• Signature EIP-712 de Polymarket — la signature d'ordre est déterministe, mais les erreurs d'outillage sont fréquentes. Utilisez py-order-utils plutôt que de coder la vôtre. La plupart des pertes des premiers bots viennent de signatures mal formées que l'API rejette silencieusement.
• Limites de débit Kalshi — documentées à 100 req/sec mais plus basses sur certains endpoints les jours d'événements chargés (soirées électorales, FOMC). Intégrez du retry-with-backoff dans votre client.
• Pics de gas Polymarket — le gas Polygon peut bondir les jours de gros volume. Polymarket subventionne la plupart des passages d'ordres via méta-transactions, mais le règlement et le retrait sont à la charge de l'utilisateur. Tenez-en compte dans vos calculs de P&L.
• Désaccords de règlement — des équivalents apparents se résolvent parfois différemment. Lisez toujours les clauses de source de résolution des deux contrats avant un pair-trade.
• Déconnexions WebSocket — les deux places connaissent des coupures WebSocket de routine. Une logique de reconnexion avec rejeu par numéro de séquence est non négociable pour tout bot en production.

Choisir vite

Où ça va

Les marchés prédictifs reçoivent en ce moment une attention grand public inhabituelle : volumes plus élevés autour des élections US, des événements FOMC, du sport et des questions de décollage de l'IA ; intégrations plus larges avec des sites d'actualité qui font remonter les probabilités implicites ; et une vague d'outillage développeur (Show HN, dépôts GitHub) qui converge sur le même thème — « quelqu'un devrait écrire CCXT pour les marchés prédictifs. »

Nous ne pensons pas qu'une bibliothèque d'exécution unifiée à la CCXT soit la bonne forme. Les différences d'auth, de règlement et de régime réglementaire sont trop profondes pour être abstraites proprement sans mentir à l'utilisateur. Mais le problème de découverte — à partir d'une question en langage naturel, trouver les contrats qui existent déjà — est résoluble par la recherche sémantique, et c'est ce que fait API Pick Prediction Markets Search. Trouvez le contrat ; passez l'ordre sur la place.

Écrit par

Sarah Choy

CEO, API Pick

Sarah Choy est CEO d'API Pick. Elle écrit sur la création d'APIs prêtes pour la production destinées aux agents IA et aux workflows LLM.