# Trading Clients, SDKs & Bots

Libraries and bots that sit between you and an event exchange, running on your keys. Who maintains them, when they last shipped, what breaks.

*https://predictionmarkets.tools/categories/trading-clients-and-bots*

## What this category is for

Everything else in this catalogue is something you read. This is the part you run. A client, an
SDK or a bot is code that holds a credential — an exchange API key, or on the on-chain venues a
wallet private key — and sends orders with it. That changes which questions matter. A data API is
judged on coverage and latency; a trading client is judged on whether it still works, who fixes it
when it stops, and what it does with the key while it runs.

Four facts decide almost every choice here, and none of them is a feature. Three are about
whether the code still works and what it does with your key. The fourth only applies to part of
the listing, and it is the one nobody expects: some of these take a cut.

## Who maintains it

**An official SDK and a third-party client are different products with the same shape.** The
official one is generated from, or written against, the venue's own API specification, so it is
usually complete and usually first to carry a new endpoint. It is also entirely at the venue's
discretion: the same company can stop publishing it, and does. Polymarket archived
[py-clob-client](https://predictionmarkets.tools/tools/py-clob-client) and put a notice at the top of its README saying the client
is no longer functional and should not be used. That is the official SDK.

A third-party client is maintained by whoever wants it maintained, which is better when they do and
worse when they stop. The useful question is not "official?" but "who has shipped a fix in the last
quarter, and for whom".

There is a second trap in the name. The obvious package name on PyPI or npm is often not the
venue's — `polymarket` and `polymarket-sdk` are both taken on PyPI by unrelated authors, while
Polymarket's current SDK installs as `polymarket-client`. Check the publisher and what the package
actually does, not just that `pip install` succeeded.

## When it last shipped

**Liveness is a set of dates, never an adjective.** Every card in this category carries the last
release and its date, the last commit on the default branch, and whether the repository is
archived. A README that says "actively maintained" is a sentence somebody wrote once.

This matters more here than it does for a charting tool. A prediction-market API is young and moves
fast: authentication schemes change, order types are added, endpoints move hosts. When the venue
ships that change, an unmaintained client does not warn you — it starts returning errors, or worse,
keeps working for reads and fails only on the order you cared about. Neither side announces
anything, because the venue does not know your library exists and the library has nobody left to
notice.

Ranges worth knowing: [kalshi-python](https://predictionmarkets.tools/tools/kalshi-python) last published in September 2025;
[ccxt](https://predictionmarkets.tools/tools/ccxt) publishes about weekly. Those are two very different risk profiles for the same
job.

## What happens when the venue changes its API

Ask, before you depend on a library, what the failure mode is. A generated client — one built
automatically from an OpenAPI specification — regenerates cheaply when the spec changes, but only
if somebody runs the generator and uploads the result. A hand-written client absorbs a change more
gracefully but needs a human who understands both ends.

A multi-venue abstraction like CCXT adds a third layer: the venue changes, the library's unified
model has to be re-mapped onto it, and your code sees either a fix or a silently different meaning
for the same field. The upside is that you write one integration instead of five. The cost is that
you are reading somebody else's translation of the exchange, and the errors you get back are the
translation's, not the exchange's.

## Open source is not the same as safe to hand a key

This is the sentence this category exists to print. **An MIT licence is permission to read the
code, not evidence that anyone did.** A trading client runs with your credential inside the same
process as every dependency it pulls in, and most of these libraries pull in a dozen.

Concretely, before you point a client at a funded account:

- **Know which credential it wants.** An exchange API key that can be scoped to trading is a
  different level of exposure from a wallet private key that can move funds. On the on-chain
  venues, signing an order and moving the collateral are both done with the same key.
- **Know what it uploads.** A client that signs locally and posts a signed payload is doing the
  right thing; a client that asks for a key so it can call a service you do not control is not.
- **Check the dependency list, not just the repository.** Supply-chain risk lands in the same
  process as the key.
- **Separate the read path from the trade path.** Most of these libraries work unauthenticated for
  prices and order books. Anything you are only reading does not need a key at all.

Nothing in this category has been run against a funded account by this site, so every card here is
`hands_on: false`. The dates, the licences, the dependency lists and the method inventories are
read out of the repositories and the published packages; the behaviour under load is not something
we are claiming.

## Some of them charge you, and the venue's fee is not the whole fee

A library takes nothing. You install it, it signs an order, and what the fill costs is whatever the
venue charges — the curve on its card, and nothing else. That is true of every SDK in this listing
and it is why the fee fields on those cards are empty.

**It stops being true the moment the product has a front end.** A consumer app that routes your
order to somebody else's order book has an obvious place to take a margin, and it is inside the
fill, where you will not see it as a line item.

[Polycool](https://predictionmarkets.tools/tools/polycool) is the explicit version: a percentage of every successful trade, on a
ladder that starts at 1.00% and falls to 0.50% on lifetime volume, with a floor of three cents per
execution — which makes a small copy proportionally far more expensive than the headline rate. That
is charged on top of whatever Polymarket takes, and the card says so in its first line.

[Synthesis](https://predictionmarkets.tools/tools/synthesis) is the other version, and the more common one: no pricing page, no
fee page, and terms that run to thousands of words without mentioning a charge to the user. Its
card leaves the fee fields empty rather than setting them to zero, because empty renders as
"unknown" and zero would claim we established that nothing is taken. **Treat an unpublished fee as
unstated, not as free.**

So the question to ask a front end is not what it costs to install. It is what it takes per fill,
where that is written down, and what happens to the number as you trade more.

## What is in here so far

Most of this listing is the client-library layer, which is the part where the facts are checkable:
the official SDK each venue publishes, the unofficial ones people use instead, and the two
multi-venue abstractions. Beside them sit a terminal and a self-hosted strategy app, because a bot
you run on your own keys is the same kind of object as a library — it just comes with an interface.

What is deliberately absent is larger than what is here. The community lists carry dozens of
Polymarket bots, and most of them fail the entry test in the same three ways: no licence file, no
release and no commit inside a year, or no answer to the question of what the thing does with the
key you hand it. A hosted service that decides which contract to buy and sells you the answer is
outside this catalogue altogether — that boundary is a product one, not a technical one, and it
does not move because the product is popular.

So the listing grows one checked repository at a time, and a name we could not verify is a name
that is not here.

## Cards

- [CCXT](https://predictionmarkets.tools/tools/ccxt.md) — One client for seven prediction venues, inside a 104-exchange crypto library.
- [Kalshi Python SDK (sync and async)](https://predictionmarkets.tools/tools/kalshi-python-sync.md) — Kalshi's current official Python client - weekly releases, Python 3.13 only, no source.
- [kalshi-python](https://predictionmarkets.tools/tools/kalshi-python.md) — Kalshi's own generated Python client - closed-source, and unreleased since September 2025.
- [limitless-sdk](https://predictionmarkets.tools/tools/limitless-sdk.md) — Limitless Exchange's own async Python SDK - CLOB and NegRisk orders, WebSocket, MIT.
- [PMXT](https://predictionmarkets.tools/tools/pmxt.md) — CCXT-shaped client for prediction markets, with a hosted API and a self-hosted mode.
- [Polycool](https://predictionmarkets.tools/tools/polycool.md) — Phone-sized Polymarket client with copy trading, parlays and a fee of its own.
- [Alphapoly (polymarket-alpha-bot)](https://predictionmarkets.tools/tools/polymarket-alpha-bot.md) — Self-hosted scanner for covering portfolios across correlated Polymarket contracts.
- [Polymarket CLI](https://predictionmarkets.tools/tools/polymarket-cli.md) — Polymarket's Rust command line - MIT in the manifest, with no LICENSE file in the repo.
- [polymarket-client](https://predictionmarkets.tools/tools/polymarket-client.md) — Polymarket's own unified Python SDK - sync and async, data through order signing.
- [Polymarket US Python SDK](https://predictionmarkets.tools/tools/polymarket-us-python.md) — Official SDK for Polymarket US - installs as polymarket-us, unreleased since January.
- [Polymarket US TypeScript SDK](https://predictionmarkets.tools/tools/polymarket-us-typescript.md) — Official TypeScript client for Polymarket US - npm has shipped nothing since January.
- [Polyrama](https://predictionmarkets.tools/tools/polyrama.md) — Polymarket and Kalshi in one terminal, with wallet analytics and a REST API.
- [py-clob-client](https://predictionmarkets.tools/tools/py-clob-client.md) — Polymarket's own Python CLOB client - archived, and declared non-functional by its README.
- [pykalshi](https://predictionmarkets.tools/tools/pykalshi.md) — Unofficial Kalshi client with what the generated SDK leaves out - streams and retries.
- [Synthesis](https://predictionmarkets.tools/tools/synthesis.md) — Polymarket and Kalshi in one browser desk, with copytrading and a shared portfolio.

## FAQ

### Is a venue's own SDK always the right one to use?

Not automatically. An official SDK tracks the venue's API and nothing else, which is what you want for one venue and useless across several. It can also be abandoned by the same company that wrote it - Polymarket archived its own Python CLOB client and told users it no longer works. Check the release dates before the badge.

### How do I tell whether a client library is still maintained?

Three dates, not an adjective. The last release and its date, the last commit on the default branch, and whether the repository is archived. A library with no release in a year is a fact you should see on the card rather than discover after your orders start failing.

### Does open source mean a trading client is safe to give an API key?

No. Open source means you may read the code and that somebody could have. A client that signs orders holds your private key or your exchange key in the same process, and every dependency it pulls in runs there too. Read what the library does with the key, and prefer keys scoped to trading with withdrawals disabled.

### Can one library trade several prediction markets at once?

Two here try - CCXT, through a dedicated prediction namespace covering seven venues, and PMXT, which is shaped after CCXT and lists fifteen. Every other client here speaks to exactly one exchange, because order signing, collateral and the shape of a market ID are different at each of them. What you gain is one integration; what you lose is that the errors come back in the library's vocabulary rather than the exchange's.