[ blog · comparison ]11 min read

API do Polymarket vs Kalshi: um guia lado a lado para desenvolvedores (auth, CLOB, WebSocket, dados históricos)

Sarah Choy·Publicado em 3 de maio de 2026·11 min de leitura

Polymarket e Kalshi rodam a mesma primitiva — contratos sim/não sobre um CLOB — através de APIs completamente diferentes. Um exige assinaturas EIP-712 e uma carteira na Polygon; o outro é um endpoint REST com FIX opcional. Se você está construindo um agente de previsão, um bot de arbitragem ou um monitor de smart money, aqui está o guia lado a lado que já deveria existir.

TL;DR

• •O Polymarket usa ordens assinadas com EIP-712 enviadas ao seu CLOB na Polygon — aplicam-se o onboarding de carteira e as taxas de gas.
• •O Kalshi usa auth padrão REST + WebSocket (e-mail/senha → token), além de um gateway FIX opcional para usuários institucionais.
• •Ambos expõem livro de ordens, negociações e dados históricos, mas o schema e a semântica de resolução diferem o suficiente para que bibliotecas 'unificadas' sejam o tema de Show HN mais solicitado neste canto do tooling cripto/quant.
• •A arbitragem entre locais sobre contratos equivalentes é o padrão de construção mais comum (mais de 10 bots open-source no GitHub).
• •O API Pick Prediction Markets Search envolve ambos os locais em um único endpoint POST para descoberta de contratos em linguagem natural — 50 créditos por chamada, resultados semânticos ranqueados.

Por que este artigo existe

Se você já passou algum tempo construindo sobre mercados de previsão, conhece o pedido canônico: 'quero consultar Polymarket e Kalshi a partir do mesmo script de Python e receber de volta uma lista limpa de contratos correspondentes.' A thread de comentários do HN em todo Show HN de mercados de previsão converge inevitavelmente para isso — há um padrão recorrente de posts de "CCXT para mercados de previsão", indicando que a demanda existe e que as soluções atuais não acertam totalmente o alvo.

A dificuldade é real. Os dois locais resolvem a mesma primitiva — contratos binários "sim/não" sobre um livro de ordens de limite central — mas os expõem através de APIs dramaticamente diferentes. Aqui está uma visão funcional de desenvolvedor de ambos, lado a lado, com o código que você realmente precisa.

Dois locais, duas arquiteturas

Polymarket

• Cadeia: Polygon (liquidações em USDC.e)
• Auth: assinatura de dados tipados EIP-712 com a chave privada de uma carteira; sem token bearer tradicional
• Colocação de ordens: ordem assinada enviada à API CLOB; o gas é pago pelo Polymarket via meta-transações
• Descoberta de mercados: a API Gamma (REST + JSON) para navegar pelos mercados ativos, mais uma API CLOB separada para o livro de ordens ao vivo
• Dados em tempo real: stream WebSocket para atualizações do livro de ordens e negociações
• Dados históricos: endpoints REST para negociações; snapshots diários baixáveis à parte

Kalshi

• Liquidação: USD via ACH e transferência (banco dos EUA exigido)
• Auth: e-mail + senha → token bearer, OU chave de API (institucional)
• Colocação de ordens: POST REST autenticado padrão para /portfolio/orders
• Descoberta de mercados: endpoints REST para eventos, mercados e séries; schema limpo
• Dados em tempo real: WebSocket e FIX (institucional) para execuções, livro de ordens, ticker
• Dados históricos: endpoints REST para negociações; dados de resolução e liquidação de mercados diretos

Lado a lado

Código funcional: hello-world em cada um

Polymarket: listar mercados ativos

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: colocar uma ordem assinada (esboço)

# 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: fazer login e colocar uma ordem de 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: descoberta em linguagem natural entre ambos

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.

Três padrões de produção que realmente funcionam

1. O bot de arbitragem entre locais

O padrão mais comum no GitHub: uma whitelist curada de "este contrato do Polymarket resolve sobre o mesmo desfecho que este contrato do Kalshi". O bot observa ambos os livros, calcula a probabilidade implícita e assume uma posição quando o spread cruza um limiar. Exemplos: ImMike/polymarket-arbitrage e realfishsam/prediction-market-arbitrage-bot.

A parte difícil é a whitelist. "O Fed vai cortar 25 pb na reunião de dezembro?" parece a mesma coisa para um humano, mas as fontes de resolução e a redação exata diferem; um casador automático erra com frequência suficiente para que os bots reais usem mapeamentos curados por humanos.

2. O monitor de smart money

As baleias no Polymarket são visíveis on-chain. Um monitor observa a Polygon em busca de grande fluxo de ordens em mercados específicos, traz à tona posições grandes e sinaliza movimentos rápidos de preço antes que as manchetes cheguem às APIs de notícias. Combine com a News Search para confirmar se um movimento aparente é impulsionado por notícias ou pura especulação.

3. O feed de previsões para um agente LLM

Trazer os preços atuais do Polymarket / Kalshi para o contexto de um agente LLM permite que o modelo dê respostas fundamentadas em probabilidade: "os mercados de apostas atuais implicam uma probabilidade de ~65% de X". Este é o caso de uso de descoberta que o API Pick cobre — dada uma pergunta em linguagem natural do agente, retorna contratos ranqueados para que o agente possa citar o preço em sua resposta.

Armadilhas comuns (compiladas dos comentários do HN)

• Assinatura EIP-712 do Polymarket — a assinatura da ordem é determinística, mas erros de tooling são comuns. Use py-order-utils em vez de fazer a sua própria. A maioria das perdas iniciais de bots vem de incompatibilidades de assinatura que a API rejeita silenciosamente.
• Limites de taxa do Kalshi — documentados em 100 req/seg, mas menores em alguns endpoints durante dias de eventos movimentados (noites de eleição, FOMC). Construa retry-with-backoff no seu cliente.
• Picos de gas do Polymarket — o gas da Polygon pode disparar em dias de grande volume. O Polymarket subsidia a maior parte da colocação de ordens via meta-transações, mas a liquidação e o saque são pagos pelo usuário. Considere isso nos cálculos de P&L.
• Incompatibilidades de liquidação — equivalentes aparentes às vezes resolvem de forma diferente. Sempre leia as cláusulas de fonte de resolução de ambos os contratos antes de operar em pares.
• Desconexões de WebSocket — ambos os locais têm quedas rotineiras de WebSocket. Lógica de reconexão com replay por número de sequência é inegociável para qualquer bot em produção.

Escolher rápido

Para onde isso está indo

Os mercados de previsão estão recebendo uma quantidade incomum de atenção mainstream agora: volumes maiores em torno das eleições nos EUA, dos eventos do FOMC, dos esportes e das questões de decolagem da IA; integrações mais amplas com sites de notícias que exibem probabilidades implícitas; e uma onda de tooling para desenvolvedores (Show HNs, repos do GitHub) que converge para o mesmo tema — 'alguém deveria escrever o CCXT para mercados de previsão.'

Não achamos que uma biblioteca de execução unificada no estilo CCXT seja a forma certa. As diferenças em auth, liquidação e regime regulatório são profundas demais para abstrair com limpeza sem mentir para o usuário. Mas o problema de descoberta — dada uma pergunta em linguagem natural, encontrar os contratos que já existem — é, sim, resolúvel com busca semântica, e é isso que o API Pick Prediction Markets Search faz. Encontre o contrato; coloque a ordem no local.

Escrito por

Sarah Choy

CEO, API Pick

Sarah Choy é a CEO da API Pick. Ela escreve sobre a construção de APIs prontas para produção para agentes de IA e fluxos de trabalho com LLMs.