Prediction Market SDKs & Client Libraries

What this category is for

A library you import into your own program to read a venue's markets and sign orders on it. Ten packages sit here: the official SDKs Kalshi, Polymarket, Polymarket US and Limitless publish for their own exchanges, one third-party Kalshi client written to fill the gaps in the official one, and the two multi-venue abstractions, CCXT and PMXT. A terminal, a copy-trading app or a bot you run rather than write is in trading clients and bots. Reading prices with plain HTTP and no client at all is market data APIs — every venue here answers its read endpoints without a library.

A library is judged on different things from a product. It takes no fee, so price is not the question. Whether it still works when the venue changes its API is, and so is what it does with the credential it holds while it runs.

Where to start, by venue:

• Polymarket (international, on-chain): polymarket-client, Polymarket's own. Not py-clob-client, which Polymarket archived.
• Polymarket US: the Python SDK or the TypeScript one. A different exchange and a different API from the one above, and neither package reaches the other.
• Kalshi: kalshi_python_sync / async for complete, weekly-generated REST coverage; pykalshi for streaming, a local order book and Python below 3.13. kalshi-python is the deprecated package.
• Limitless: limitless-sdk, the exchange's own, async only.
• Several venues behind one interface: CCXT, or PMXT for wider coverage and a hosted mode. The head to head takes both against Polymarket's two official Python clients.

Who publishes it, and how you can tell

Official is a fact about the publisher, not a promise about the code. Seven of the ten packages are the venue's own, and two of those seven are packages the venue itself has walked away from. Polymarket archived py-clob-client and put a warning at the top of its README that the client no longer functions — while the PyPI page carries no warning at all, so pip install py-clob-client still succeeds. Kalshi's SDK documentation marks kalshi-python deprecated; it last shipped on 6 September 2025.

Official is not the same as open. Both of Kalshi's Python packages declare a proprietary licence and name a repository, Kalshi/exchange-infra, that returns 404 to the public. You can read the generated Python inside the wheel and nothing else: no history, no issue tracker, no way to send a patch. If your compliance process wants a named open-source licence on every dependency in an order path, those two will not pass it. Every other package here is MIT.

The obvious install name is often somebody else's. On PyPI, polymarket and polymarket-sdk are unrelated authors' packages; Polymarket's own is polymarket-client, imported as polymarket. The scoped @polymarket/* names on npm belong to the international platform, and Polymarket US publishes a single unscoped polymarket-us. A clean pip install proves only that a package by that name exists.

When it last shipped

Liveness is a set of dates, never an adjective. Each card here carries the last release, the last commit on the default branch, and whether the repository is archived, and the spread is wide:

• Weekly. Kalshi says its current Python packages are regenerated from the OpenAPI specification and released ahead of the API change, usually on a Tuesday or Wednesday — 3.30.0 on 15 September 2026. CCXT shipped 39 releases in the six months to 19 September 2026.
• Recent and frequent. limitless-sdk released 1.1.1 on 17 September 2026, the same day as its last commit. polymarket-client reached 0.10.0 on 10 September 2026, its thirty-fourth release since May — and that release changed how data reads work, which is what a 0.x version number warns you about. Pin it.
• Stopped, or stalled. PMXT published 322 releases between January and July 2026 and nothing after 18 July. pykalshi is one author's library, last released on 27 July 2026.
• Released code behind the repository. The two Polymarket US packages were last published to PyPI and npm in January 2026, while their repositories took fixes as late as 17 September. What you install is not what you read on GitHub; install from git if you need the fix.

A generated client is only as current as the last time someone ran the generator and uploaded the result. An endpoint the venue added since then is simply missing, and you find out from an AttributeError, not from a changelog.

Which key it holds, and what that key can do

Every package here that places an order holds a credential in your process, and the word "key" covers three different objects:

• A wallet private key on the on-chain venues. polymarket-client and limitless-sdk sign orders locally with it and post signed payloads. On Polymarket the key that signs an order is the key that can move the collateral. Polymarket's SDK also supports scoped, revocable session keys, which is the one documented way here to give a script trading authority without withdrawal authority.
• An RSA key pair on Kalshi. Generated in the account settings, used to sign every request; it can trade the account until you revoke it on Kalshi. The official packages and pykalshi both sign in process.
• An Ed25519 API credential on Polymarket US. An exchange credential issued from a verified account's developer page. No wallet, no allowance, no on-chain approval step — so the Polygon approval failure that was the most common first error with the archived Polymarket client does not exist on that side.

The multi-venue libraries add a question. PMXT's default, hosted path puts a PMXT service key and your venue private key in the same constructor; its docs describe a split in which signing never leaves your process, and say the contracts behind it were unaudited as of 9 June 2026. Its self-hosted mode keeps venue credentials on your machine. The guide to where your key lives goes through the difference in full.

What happens when the call fails

Two behaviours decide whether a network error costs you a duplicate order, and they are opposite in two packages here. The Polymarket US Python SDK retries idempotent requests with backoff and never retries order placement, so a timeout cannot submit the same order twice. pykalshi retries every method, order placement included, on a timeout, a 429 or a 5xx; an order that reached Kalshi but timed out on the way back is sent again as a new order unless you pass your own client_order_id. The TypeScript twin of the Polymarket US SDK retries nothing at all. Why your bot gets throttled covers the rate limits that set the retries off.

Nor is there anywhere safe to rehearse on most of these. polymarket-client exports one environment, production. limitless-sdk and pykalshi have no paper mode. The Polymarket US SDKs can preview an order without submitting it, which prices it and proves nothing about the fill. Kalshi runs a demo environment, and pointing a client at it is your job.

Streaming is the gap the official packages leave

A program that has to stay connected needs the WebSocket half of a venue's API, and it is the part official SDKs most often leave out. Kalshi's official Python packages are REST only; streaming is in a separate specification and you write that client yourself, or use pykalshi, which streams and keeps a local order book from the deltas. polymarket-client and the Polymarket US Python SDK stream from their async clients only, so a synchronous script has to poll or grow an event loop; the Polymarket US TypeScript package refuses to open a stream in a browser at all. CCXT streams for three of its seven prediction venues — Polymarket, Myriad and Opinion — and leaves the other four to polling or your own socket code.

One interface over several venues, and what it costs

A unified API is somebody else's translation of each exchange. When a field means different things on Polymarket and Kalshi, the library has picked one mapping, and the error you get back is its rendering of the venue's error rather than the venue's own. For one venue, the venue's own SDK or its raw API is always closer to the truth.

What you get for it is one integration instead of several, and coverage that differs more than the headline numbers suggest. CCXT is a 104-exchange crypto library with a seven-venue prediction namespace inside it; every one of the seven places and cancels orders, and capability varies enough that exchange.has is required reading. Its Python prediction classes are async only. PMXT lists fifteen venues and writes to three of them through its hosted service. Its plans are for personal use only, by its own pricing page, and its issue tracker held 1,236 open issues on 19 September 2026.

What to check before you depend on one

• The three dates. Last release, last commit, archived or not — on the package index as well as the repository.
• The interpreter floor. Kalshi's current SDK needs Python 3.13; polymarket-client 3.11; limitless-sdk accepts 3.8. A floor can rule a package out of your production image before anything else does.
• Which credential it asks for, and where it signs. In process, with a key scoped to trading where the venue allows it, and withdrawals disabled or out of reach.
• Whether it retries an order. If it does, pass your own client order id on every one.
• Which exchange it actually reaches. One vendor can run two venues; Polymarket and Polymarket US share a name, and their SDKs share nothing.