Trading Clients, SDKs & 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 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 last published in September 2025; 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 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 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.