Python Libraries for Prediction-Market Trading: Polymarket and Kalshi

If you want to trade Polymarket or Kalshi from Python, the ecosystem splits cleanly along the two venues. Each has an official SDK plus a handful of community libraries that fill in the parts the official one skips. This is a map of what exists as of July 2026, what each library actually does, and where you still have to write code yourself.

Polymarket: the CLOB clients

Polymarket runs a central limit order book off-chain and settles on Polygon. Its data surface is split across three services, and knowing which is which saves you hours. Gamma is market discovery and metadata, the CLOB is the order book and trading layer, and the Data API exposes user-level positions and history.

The important detail: the two you touch most are Gamma and the CLOB. Gamma tells you what markets exist and hands you the token IDs; the CLOB gives you live depth, price history, and order placement. New traders routinely start at the CLOB, then get stuck because it wants a token ID they can only get from Gamma.

The SDK landscape shifted sharply in April and May 2026. On April 28, 2026, Polymarket cut production over to CLOB V2: new Exchange contracts, a rewritten CLOB backend, and a new collateral token (pUSD). There is no backward compatibility. The original py-clob-client was archived on May 11, 2026, and V1-signed orders no longer work against production. If any integration in your stack still references py-clob-client (V1), it is not trading.

The current path for Python: Polymarket has released a unified py-sdk that folds the REST APIs and WebSockets into one package and is the recommended starting point for new projects. Both the archived py-clob-client and the intermediate py-clob-client-v2 now direct developers to py-sdk. If you are starting fresh, use py-sdk; if you are migrating an existing V2 bot, py-clob-client-v2 still works but the same upstream message applies.

Authentication is wallet-based rather than a traditional API key. Gamma read endpoints are public and unauthenticated; the CLOB derives API credentials from your Polygon wallet's private key and requires EIP-712 signed payloads to place orders. Collateral is pUSD, a USDC-backed ERC-20 on Polygon. API-only traders wrap USDC.e into pUSD via the Collateral Onramp contract; the Polymarket UI handles wrapping automatically for browser users.

Kalshi: official SDK plus community depth

Kalshi is a US exchange for binary event contracts, regulated by the CFTC as a Designated Contract Market. It publishes official Python and TypeScript SDKs. The Python one is kalshi-python, installable via pip. Kalshi is candid that the SDKs are generated from the OpenAPI spec, update periodically, and can lag the live API, so active traders should treat the REST OpenAPI and WebSocket AsyncAPI specs as the source of truth.

That 'auto-generated' caveat is why community libraries exist. Several add the production plumbing the generated SDK leaves out. Examples in the wild:

• pykalshi (unofficial): WebSocket streaming, automatic retry/backoff, rate-limit handling, a local order book, pandas integration, and typed exceptions like InsufficientFundsError and RateLimitError.
• TexasCoding/kalshi-python-sdk: a spec-first client advertising full REST coverage, typed Pydantic v2 models, sync and async on one transport, and safe retry defaults where only idempotent verbs retry so a POST never fires twice.
• kalshi-py and other OpenAPI-generated clients: thin, type-safe wrappers rebuilt from the spec, useful if you want coverage over ergonomics.

The detail that trips up nearly every first Kalshi integration is authentication. There is no simple bearer token. Kalshi uses per-request RSA-PSS signatures: you generate an RSA key pair, upload the public key in your dashboard, and sign every authenticated request with a message built from a millisecond timestamp, the HTTP method, and the request path, then attach the KALSHI-ACCESS-KEY, KALSHI-ACCESS-TIMESTAMP, and KALSHI-ACCESS-SIGNATURE headers.

Common failure modes are clock skew, hashing the path with the query string still attached, or lowercasing the method, all of which return a 401 or 403 with nothing obvious to point at. The upside: once your signing function is correct, there is no login endpoint or session token to refresh. Every request stands on its own.

Data and analysis libraries

Beyond execution SDKs, a few libraries handle ingestion and analysis. dlt can load Polymarket's Gamma events and markets into a warehouse like DuckDB with pagination and schema evolution handled for you. Both venues expose historical price data directly: Polymarket's CLOB has a prices-history endpoint that returns share-price candles per outcome token, and Kalshi's SDKs increasingly ship optional pandas or polars extras so market lists come back as DataFrames.

For research workflows there are also MCP servers (for example Parlay and community Polymarket MCP servers) that pipe market data into AI assistants. Useful for exploration, not a substitute for an execution path.

Where the gaps are

The libraries get you a connection and order placement. They do not get you a trading system. The recurring holes:

• No paper trading on Polymarket. Polymarket has no testnet or paper mode, so testing order placement means real funds. Kalshi at least offers a functionally identical demo environment with separate keys, though demo liquidity is simulated.
• No risk layer. None of these SDKs enforce a per-trade cap, a daily loss stop, a max-open-positions limit, or a kill switch. That is your code.
• No cross-venue abstraction. Polymarket signs with an Ethereum wallet and settles in pUSD on Polygon; Kalshi signs with RSA and settles in USD. A strategy that trades both ends up maintaining two auth stacks and two order models.
• Retry safety is uneven. The better community clients only retry idempotent verbs, but roll your own carefully or a naive backoff can double-submit an order.

This last layer is the gap Banger targets. You write a strategy against a single interface, paper-trade it against the live order book, then run it under a declarative risk envelope (per-trade cap, daily loss stop, max open positions, kill switch). It does not custody funds; you bring your own venue keys, so the official SDKs above still sit underneath. Install and dry-run looks like this:

pip install bangertrades
banger run strategy.py --paper

How to choose

For Polymarket, start with py-sdk (the unified SDK Polymarket now recommends for new projects), use Gamma for discovery, and the CLOB for execution. Note that pUSD is the collateral token as of April 2026; budget time to set up the Collateral Onramp wrap step if you are working API-only. For Kalshi, use the official kalshi-python for coverage but pull in a community client like pykalshi if you need WebSocket streaming, a local order book, or sane retry behavior, and always develop against the demo environment first. Then decide honestly whether you want to hand-build the risk and paper-trading layer or use something that already has it.

Whatever you pick, treat every API detail as perishable. Both venues have changed their SDKs and endpoints materially in 2026 alone. Re-check the official reference before you deploy capital.