[ blog · comparison ]11 min read

Polymarket vs Kalshi API: Ein Entwickler-Direktvergleich (Auth, CLOB, WebSocket, historische Daten)

Sarah Choy·Veröffentlicht am 3. Mai 2026·11 Min. Lesezeit

Polymarket und Kalshi betreiben dasselbe Primitiv — Ja/Nein-Kontrakte auf einem CLOB — über völlig verschiedene APIs. Die eine verlangt EIP-712-Signaturen und ein Polygon-Wallet; die andere ist ein REST-Endpoint mit optionalem FIX. Wenn du einen Prognose-Agenten, einen Arbitrage-Bot oder einen Smart-Money-Monitor baust, hier ist der Direktvergleich, den es längst geben sollte.

Auf einen Blick

• •Polymarket nutzt EIP-712-signierte Orders, die an seinen CLOB auf Polygon übermittelt werden — Wallet-Onboarding und Gas-Gebühren fallen an.
• •Kalshi nutzt Standard-REST + WebSocket-Auth (E-Mail/Passwort → Token) plus ein optionales FIX-Gateway für institutionelle Nutzer.
• •Beide exponieren Order Book, Trades und historische Daten, aber Schema und Resolution-Semantik unterscheiden sich genug, dass 'vereinheitlichte' Bibliotheken das meistgefragte HN-Show-HN-Thema in dieser Ecke des Crypto-/Quant-Toolings sind.
• •Cross-Venue-Arbitrage zwischen äquivalenten Kontrakten ist das häufigste Build-Muster (10+ Open-Source-Bots auf GitHub).
• •API Pick Prediction Markets Search bündelt beide Plattformen in einem POST-Endpoint für natürlichsprachige Kontraktentdeckung — 50 Credits pro Call, gerankte semantische Ergebnisse.

Warum es diesen Artikel gibt

Wenn du je Zeit damit verbracht hast, auf Prediction Markets zu bauen, kennst du die kanonische Anfrage: 'Ich will Polymarket und Kalshi aus demselben Python-Skript abfragen und eine saubere Liste passender Kontrakte zurückbekommen.' Der HN-Kommentarthread zu jedem Prediction-Market-Show-HN konvergiert unweigerlich darauf — es gibt ein wiederkehrendes Muster von "CCXT für Prediction Markets"-Posts, was zeigt: Die Nachfrage existiert und die vorhandenen Lösungen treffen es nicht ganz.

Die Schwierigkeit ist real. Die beiden Plattformen lösen dasselbe Primitiv — binäre "Ja/Nein"-Kontrakte auf einem zentralen Limit-Orderbuch — exponieren sie aber über dramatisch verschiedene APIs. Hier ist eine praxisnahe Entwicklersicht auf beide, im Direktvergleich, mit dem Code, den du tatsächlich brauchst.

Zwei Plattformen, zwei Architekturen

Polymarket

• Chain: Polygon (USDC.e-Settlements)
• Auth: EIP-712-Typed-Data-Signing mit einem Wallet-Private-Key; kein klassischer Bearer-Token
• Order-Platzierung: signierte Order an die CLOB API übermittelt; Gas von Polymarket via Meta-Transaktionen bezahlt
• Marktentdeckung: Gamma API (REST + JSON) zum Durchstöbern aktiver Märkte, plus eine separate CLOB API für das Live-Orderbuch
• Echtzeitdaten: WebSocket-Stream für Orderbuch-Updates und Trades
• Historische Daten: REST-Endpoints für Trades; tägliche Snapshots separat herunterladbar

Kalshi

• Settlement: USD via ACH und Überweisung (US-Bankkonto erforderlich)
• Auth: E-Mail + Passwort → Bearer-Token, ODER API-Key (institutionell)
• Order-Platzierung: standard-authentifizierter REST-POST an /portfolio/orders
• Marktentdeckung: REST-Endpoints für Events, Märkte und Serien; sauberes Schema
• Echtzeitdaten: WebSocket und FIX (institutionell) für Fills, Orderbuch, Ticker
• Historische Daten: REST-Endpoints für Trades; Marktauflösung und Settlement-Daten unkompliziert

Direktvergleich

Lauffähiger Code: Hello-World auf jeder

Polymarket: aktive Märkte auflisten

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: eine signierte Order platzieren (Skizze)

# 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: einloggen und eine Limit-Order platzieren

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: natürlichsprachige Entdeckung über beide

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.

Drei Produktionsmuster, die tatsächlich funktionieren

1. Der Cross-Venue-Arbitrage-Bot

Das häufigste Muster auf GitHub: eine kuratierte Whitelist von "dieser Polymarket-Kontrakt wird auf dasselbe Ergebnis aufgelöst wie dieser Kalshi-Kontrakt." Der Bot beobachtet beide Orderbücher, berechnet die implizite Wahrscheinlichkeit und nimmt eine Position ein, wenn der Spread eine Schwelle überschreitet. Beispiele: ImMike/polymarket-arbitrage und realfishsam/prediction-market-arbitrage-bot.

Der schwierige Teil ist die Whitelist. "Will the Fed cut by 25 bps at the December meeting" sieht für einen Menschen gleich aus, aber die Resolution-Quellen und der genaue Wortlaut unterscheiden sich; ein automatischer Matcher liegt oft genug falsch, dass echte Bots menschlich kuratierte Mappings verwenden.

2. Der Smart-Money-Monitor

Wale auf Polymarket sind on-chain sichtbar. Ein Monitor beobachtet Polygon auf großen Order-Flow bei bestimmten Märkten, hebt große Positionen hervor und markiert schnelle Preisbewegungen, bevor Schlagzeilen die News-APIs erreichen. Kombiniere mit News Search, um zu bestätigen, ob eine scheinbare Bewegung newsgetrieben oder reine Spekulation ist.

3. Der Prognose-Feed für einen LLM-Agenten

Aktuelle Polymarket-/Kalshi-Preise in den Kontext eines LLM-Agenten zu ziehen, ermöglicht dem Modell wahrscheinlichkeitsgestützte Antworten: "aktuelle Wettmärkte implizieren ~65 % Wahrscheinlichkeit für X". Das ist der Discovery-Anwendungsfall, den API Pick abdeckt — gegeben eine natürlichsprachige Frage vom Agenten, gerankte Kontrakte zurückgeben, damit der Agent den Preis in seiner Antwort zitieren kann.

Häufige Stolperfallen (aus HN-Kommentaren zusammengetragen)

• Polymarket-EIP-712-Signing — die Order-Signatur ist deterministisch, aber Tooling-Fehler sind häufig. Nutze py-order-utils, statt selbst zu basteln. Die meisten frühen Bot-Verluste kommen von Signatur-Mismatches, die die API stillschweigend ablehnt.
• Kalshi-Rate-Limits — dokumentiert mit 100 req/sec, aber niedriger für einige Endpoints an geschäftigen Event-Tagen (Wahlnächte, FOMC). Bau Retry-with-Backoff in deinen Client ein.
• Polymarket-Gas-Spikes — Polygon-Gas kann an volumenstarken Tagen springen. Polymarket subventioniert die meiste Order-Platzierung via Meta-Transaktionen, aber Settlement und Auszahlung zahlt der Nutzer. Berücksichtige das in P&L-Berechnungen.
• Settlement-Mismatches — scheinbare Äquivalente werden manchmal unterschiedlich aufgelöst. Lies vor dem Paar-Handel immer die Resolution-Source-Klauseln beider Kontrakte.
• WebSocket-Disconnects — beide Plattformen haben routinemäßige WebSocket-Aussetzer. Reconnect-Logik mit Sequenznummern-Replay ist für jeden produktiven Bot nicht verhandelbar.

Schnell entscheiden

Wohin das geht

Prediction Markets bekommen gerade ungewöhnlich viel Mainstream-Aufmerksamkeit: größere Volumina rund um US-Wahlen, FOMC-Events, Sport und AI-Takeoff-Fragen; breitere Integrationen mit News-Sites, die implizite Wahrscheinlichkeiten einblenden; und eine Welle von Developer-Tooling (Show HNs, GitHub-Repos), die auf dasselbe Thema konvergiert — 'jemand sollte CCXT für Prediction Markets schreiben.'

Wir glauben nicht, dass eine CCXT-artige vereinheitlichte Execution-Bibliothek die richtige Form ist. Die Unterschiede in Auth, Settlement und Regulierungsregime sind zu tief, um sie sauber zu abstrahieren, ohne den Nutzer zu belügen. Aber das Discovery-Problem — gegeben eine natürlichsprachige Frage, finde die bereits existierenden Kontrakte — ist mit semantischer Suche lösbar, und genau das tut API Pick Prediction Markets Search. Finde den Kontrakt; platziere die Order auf der Plattform.

Geschrieben von

Sarah Choy

CEO, API Pick

Sarah Choy ist CEO von API Pick. Sie schreibt über produktionsreife APIs für KI-Agenten und LLM-Workflows.