[ blog · comparison ]11 min read

Polymarket vs Kalshi API:開發者並排指南(Auth、CLOB、WebSocket、歷史資料)

Sarah Choy2026年5月3日 發佈約 11 分鐘閱讀
Polymarket vs Kalshi API:開發者並排指南(Auth、CLOB、WebSocket、歷史資料)

Polymarket 與 Kalshi 跑的是同一個基本元件 —— CLOB 上的 yes/no 合約 —— 卻透過完全不同的 API。一個要求 EIP-712 簽章與 Polygon 錢包;另一個是一個 REST 端點,外加可選的 FIX。如果你正在打造預測 agent、套利機器人或聰明錢監控,這裡是那份早該存在的並排指南。

一句話總結

  • Polymarket 使用 EIP-712 簽章的訂單,提交到它在 Polygon 上的 CLOB —— 涉及錢包接入與 gas 費。
  • Kalshi 使用標準 REST + WebSocket 認證(email/密碼 → token),外加供機構使用者選用的 FIX 閘道。
  • 兩者都暴露訂單簿、成交與歷史資料,但 schema 與結算語意差異夠大,使得「統一」函式庫成為加密 / 量化工具這個角落裡 HN Show HN 最常被要求的主題。
  • 在等價合約間做跨場所套利,是最常見的開發模式(GitHub 上有 10+ 個開源機器人)。
  • API Pick Prediction Markets Search 用一個 POST 端點包了兩個場所,做自然語言合約發現 —— 每次呼叫 50 credits,ranked 語意結果。

這篇文章為何存在

如果你在預測市場上做過開發,你一定知道那個經典需求:「我想用同一支 Python 腳本查詢 Polymarket 與 Kalshi,並拿回一份乾淨的相符合約清單。」每一篇預測市場的 Show HN 底下的 HN 留言串,最後都不可避免地收斂到這件事 —— 反覆出現「CCXT for prediction markets」這類貼文,顯示需求存在,而現有解法總差那麼一點。

困難是真實的。這兩個場所解決同一個基本元件 —— 中央限價訂單簿(CLOB)上的二元「yes/no」合約 —— 卻透過截然不同的 API 暴露它們。這裡是兩者並排、能運作的開發者視角,附上你真正需要的程式碼。

兩個場所,兩種架構

Polymarket

  • 區塊鏈:Polygon(USDC.e 結算)
  • Auth:以錢包私鑰做 EIP-712 typed-data 簽章;無傳統 bearer token
  • 下單:簽章後的訂單提交到 CLOB API;gas 由 Polymarket 透過 meta-transactions 代付
  • 市場發現:Gamma API(REST + JSON)用於瀏覽活躍市場,外加另一個 CLOB API 取得即時訂單簿
  • 即時資料:WebSocket 串流推送訂單簿更新與成交
  • 歷史資料:REST 端點取成交;每日快照另行下載

Kalshi

  • 結算:美元,透過 ACH 與電匯(需美國銀行)
  • Auth:email + 密碼 → bearer token,或 API key(機構)
  • 下單:標準的已認證 REST POST 到 /portfolio/orders
  • 市場發現:REST 端點取得事件、市場與系列;schema 乾淨
  • 即時資料:WebSocket 與 FIX(機構)取得成交、訂單簿、ticker
  • 歷史資料:REST 端點取成交;市場結算與清算資料直觀

並排比較

架構會變動。整合前請以各場所的文件確認流量限制、費用與 KYC 要求。
PolymarketKalshiAPI Pick
AuthEIP-712 簽章訂單 + Polygon 錢包Email/密碼 → bearer;或 API keyx-api-key header(唯讀發現)
結算Polygon 上的 USDC美元銀行轉帳(僅美國)n/a(僅搜尋)
美國合法性地理封鎖(非美國)受 CFTC 監管n/a
即時WebSocketWebSocket + FIXn/a
歷史REST 成交 + 快照REST 成交 + 結算搜尋回傳指向來源的連結
最適用途加密原生、全球市場、聰明錢追蹤受美國監管、選舉與經濟跨場所合約發現

可執行程式碼:各自的 hello-world

Polymarket:列出活躍市場

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:送出簽章訂單(骨架)

# 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:登入並送出限價單

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:跨兩個場所的自然語言發現

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.

三種真正能跑的正式環境模式

1. 跨場所套利機器人

GitHub 上最常見的模式:一份人工策展的白名單,標明「這個 Polymarket 合約與這個 Kalshi 合約就同一結果結算」。機器人盯著兩邊的訂單簿,計算隱含機率,並在價差跨過門檻時建立部位。範例:ImMike/polymarket-arbitragerealfishsam/prediction-market-arbitrage-bot

困難之處在白名單。「Will the Fed cut by 25 bps at the December meeting」對真人看起來一樣,但結算來源與確切措辭不同;自動配對器出錯的頻率高到讓真正的機器人改用人工策展的對應表。

2. 聰明錢監控

Polymarket 上的巨鯨在鏈上是可見的。一個監控器盯著 Polygon 上特定市場的大筆訂單流,浮現出大部位,並在頭條觸及新聞 API 之前標記出快速的價格變動。配上 News Search,確認一次明顯的變動究竟是新聞驅動還是純投機。

3. 給 LLM agent 的預測動態饋送

把當前的 Polymarket / Kalshi 價格拉進 LLM agent 的上下文,能讓模型給出有機率依據的回答:「current betting markets imply ~65% probability of X」。這正是 API Pick 涵蓋的發現使用情境 —— 給一個來自 agent 的自然語言問題,回傳 ranked 合約,讓 agent 能在回答中引用價格。

常見陷阱(彙整自 HN 留言)

  • Polymarket EIP-712 簽章 —— 訂單簽章是決定性的,但工具層級的錯誤很常見。請用 py-order-utils,別自己手刻。早期機器人的虧損多半來自被 API 默默拒絕的簽章不符。
  • Kalshi 流量限制 —— 文件標為 100 req/sec,但在繁忙的事件日(選舉夜、FOMC)某些端點會更低。在你的客戶端內建退避重試。
  • Polymarket gas 飆升 —— Polygon 的 gas 在大交易量日會跳高。Polymarket 透過 meta-transactions 補貼多數下單,但結算與提領是使用者付費。在損益計算中把這算進去。
  • 結算不一致 —— 看似等價的合約有時結算方式不同。配對交易前,務必讀完兩個合約的結算來源條款。
  • WebSocket 斷線 —— 兩個場所都有例行的 WebSocket 抖動。對任何正式環境機器人,帶序號重播的重連邏輯沒得商量。

快速選型

最佳場景:受美國監管的交易
Kalshi。CFTC 監督、美元結算、無加密接入。任何鎖定美國使用者的產品的正確答案。
最佳場景:加密原生、全球、聰明錢追蹤
Polymarket。Polygon 原生意味著鏈上訂單流可觀測;事件覆蓋更廣,尤其在地緣政治、加密與娛樂。
最佳場景:跨場所套利
兩者搭配。先針對其中一個(通常選 auth 較乾淨的 Kalshi)建機器人;待你的配對邏輯穩固後再加上 Polymarket。
最佳場景:LLM agent 裡的自然語言合約發現
API Pick Prediction Markets Search。一個 POST,回傳跨兩個場所的 ranked 配對,每次呼叫 50 credits,僅在成功時計費。立即試用 →

趨勢往哪走

預測市場現在正獲得不尋常的大量主流關注:美國選舉、FOMC 事件、體育與 AI 起飛問題前後交易量更大;與浮現隱含機率的新聞網站整合更廣;還有一波開發者工具(Show HN、GitHub repo)收斂到同一主題 —— 「someone should write CCXT for prediction markets。」

我們不認為 CCXT 風格的統一執行函式庫是正確的形態。auth、結算與監管制度上的差異太深,無法在不對使用者說謊的前提下乾淨地抽象掉。但發現問題 —— 給一個自然語言問題,找出早已存在的合約 —— 是可以用語意搜尋解決的,而這正是 API Pick Prediction Markets Search 在做的事。找到合約;到場所下單。

常見問題

哪個場所的合約比較多?

撰寫當下,兩者都列有數萬個活躍市場。Polymarket 偏向加密原生且全球化(政治、體育、加密、時事);Kalshi 受 CFTC 監管且以美國為主(選舉、經濟、天氣、體育)。交易量分布因類別而異 —— 美國選舉通常 Kalshi 較深;全球政治與加密原生的問題則是 Polymarket。

為什麼開源「統一」函式庫一直冒上 Show HN?

因為需求存在,而沒人把它做好。像「Open-source library to unify Polymarket and Kalshi APIs」與「dr-manhattan — CCXT for Prediction Markets」這類 Show HN 貼文是反覆出現的模式。難點在於配對等價合約(相同結果、不同措辭)並調和結算語意。函式庫通常能搞定 auth 包裝,卻在合約配對前止步。

我要怎麼做基本的跨場所套利?

概念上:找兩個在不同場所、就同一結果結算的合約,檢查隱含機率,買進報價較高的「No」邊與報價較低的「Yes」邊,持有到結算。實務上的摩擦在執行:Polymarket 的 gas 費、Kalshi 的美元入金、部分成交,以及上面那個配對問題。GitHub 上多數實盤套利機器人,跑的是一份人工策展的合約配對白名單,而不是自動發現。

Polymarket 在美國合法嗎?

Polymarket 目前未獲准供美國使用者使用;存取會做地理封鎖。Kalshi 受 CFTC 監管,在美國合法。如果你正在為美國使用者打造產品,Kalshi 是唯一選項。如果你做的是全球性產品,Polymarket 的市場覆蓋更廣。

API Pick 在這套技術堆疊裡擺在哪?

API Pick Prediction Markets Search 解決「發現」問題:給一個自然語言問題(例如「Fed cuts rates by year-end」),它用一次 POST 呼叫回傳跨 Polymarket 與 Kalshi 合約的 ranked 語意配對。我們不取代下單執行的 API —— 要下單你仍直接去各場所。我們讓「找到對的市場」變得容易。

本文使用的 API

Sarah Choy
作者
Sarah Choy
CEO, API Pick

Sarah Choy 是 API Pick 的 CEO,專注於為 AI Agent 與 LLM 工作流打造可用於正式環境的 API。