The Polymarket SDK in 2026: Which One to Install and Why

Choosing a Polymarket SDK in 2026 is annoying for one reason: the correct answer changed twice this year, and the wrong answer has a multi-year head start on search rankings, GitHub stars and every model's training data. Search this and you land on py-clob-client, the package with 1,235 stars, three quarters of a million monthly downloads, and an archive notice at the top of its README.

This page is about picking the install line and knowing what it buys you. Everything below was checked against PyPI, npm, GitHub and Polymarket's docs on 9 August 2026, and the sources are linked inline so you can recheck them. Versions on a 0.x library move fast, so confirm before you pin.

Which Polymarket SDK Is Current

pip install polymarket-client     # then: import polymarket
pnpm add @polymarket/client       # or npm i @polymarket/client

The Python source lives at Polymarket/py-sdk and the TypeScript at Polymarket/ts-sdk, and the two are versioned in lock step, both at 0.5.0 when this was written. Check your runtime before getting attached. polymarket-client requires Python 3.11 or newer, up from 3.9.10 on the retired client, and @polymarket/client declares node 24 or newer in its engines field. That node floor is aggressive and it is the thing most likely to block a migration in an older codebase.

Both READMEs carry the same warning: "Although minor releases on the 0.x line may include breaking changes, we aim to avoid them and, whenever possible, provide a deprecation path." Pin an exact version anyway.

One thing the install line does not tell you is surface area, so check that before you commit. The unified client covers both halves of the exchange in a single package: a PublicClient for unauthenticated market reads, and a secure client for the signed write path, returning typed models where the old clients handed back raw dicts. It does not abstract the exchange away from you. Read the client reference in the repo and confirm the specific calls your build needs are actually there, because at 0.5.0 that surface is still moving.

Every Python and TypeScript Package You Will Find

A package search for a Polymarket client library returns at least eight plausible looking results. Here is the field you are most likely to hit:

That table is not the complete removal list. Polymarket's migration guide names four builder packages as well, @polymarket/builder-relayer-client, @polymarket/builder-signing-sdk, py-builder-relayer-client and py-builder-signing-sdk, all folded into the unified SDK. Check your dependency tree against that page as well as against the table here.

Other languages get thinner treatment. Rust has no unified crate yet: the migration guide says one is in progress and points Rust users at the polymarket_client_sdk_v2 crate until it lands, so read that page before you pin anything. Nothing official has shipped for Go, Java, C# or Elixir, and those readers are better served calling the HTTP API directly, which is covered under when you do not need a client library.

Row seven is worth naming out loud. The PyPI package called simply polymarket is not Polymarket's; it is an unaffiliated historical odds exporter. The official SDK installs as polymarket-client but imports as polymarket, so pip install polymarket quietly gets you somebody else's library.

The two clob-client-v2 packages are the honest grey area. Their repositories are alive, neither carries a deprecation flag, and the migration guide simultaneously lists both as packages to remove. No sunset date has been published. Keep them running if they already are, but do not start new work on them.

py-clob-client and Why It Is Still Winning

The archive notice is unusually blunt. It reads: "This repository has been archived and is no longer maintained. The client is no longer functional and should not be used for new or existing integrations." That notice landed in May 2026, and the last real code change was a tick size fix in February.

It has not dented the install count. In the month before publication the archived client recorded 734,430 downloads against 82,445 for polymarket-client, and on npm the archived @polymarket/clob-client still edged out the current client over an identical window. Downloads count installs rather than people, and CI reruns inflate both sides, so read it as a ratio. The ratio still says a lot of Polymarket integrations are being stood up right now on a dead library.

The failure is at least loud. Nothing warns you at install time, and then the first write comes back with an order_version_mismatch error: the V2 exchange refusing a V1 signed order. Issues with exactly that title were filed on the day of the 28 April 2026 cutover and are still open, with no maintainer response. Users report it across every signature type, which fits the cause: the order struct itself changed at the cutover, so a correctly signed V1 order is now simply the wrong shape.

Reads are the better news. They hit the same unauthenticated public endpoints, and what changed at the cutover was the order struct rather than the read surface, so a read only poller on the archived client will most likely keep working, right up until a response shape shifts and nobody patches it.

If you have working code on the old client, the shape of the migration is three changes rather than a rename. ClobClient splits into PublicClient for reads and AsyncSecureClient for writes, so the write path becomes async. Responses arrive as typed models instead of dictionaries, which will surface as a wave of attribute errors wherever you were doing result["field"]. And credentials move behind the new client's constructor. The migration guide carries the call by call detail.

What the SDK Handles That Raw Requests Does Not

Everything in this section describes Polymarket global, the Polygon based exchange. Polymarket US is a separate venue with a completely different auth model, covered at the end of the page.

Reads on Polymarket are genuinely public, so for market data a client library is a convenience. Writes are the opposite. Most people arrive expecting an exchange style API key, and that expectation is wrong in three separate places.

Layer one is a wallet signature: an EIP-712 typed struct called ClobAuth, domain name ClobAuthDomain, chain ID 137, carrying your address, a timestamp, a nonce and an attestation message. Send it and you get back three values rather than one, being an API key, a base64 secret and a passphrase. Layer two uses those on every private request: build a string from the timestamp, the uppercased HTTP method, the route and the body, HMAC-SHA256 it with the base64 decoded secret, then attach POLY_ADDRESS, POLY_SIGNATURE, POLY_TIMESTAMP, POLY_API_KEY and POLY_PASSPHRASE. Layer three is the part the usual two layer summary skips. The order itself carries its own EIP-712 signature, which means computing makerAmount and takerAmount differently by side, selecting the standard or negative risk exchange contract, and setting a signature type that tells the exchange how your wallet signs.

That signature type is a four entry enum, and picking wrong is a rejected order: 0 for a plain EOA, 1 for a Polymarket proxy wallet, 2 for a Gnosis Safe, 3 for a deposit wallet. Type 3 is the one to know, because per Polymarket's wallets and auth docs every account wallet deployed from 4 May 2026 onwards uses it. If you made your account this year, that is you.

Then there is rounding, where the docs are specific: price to no more than the market's price decimals, quantity rounded down to size decimals, and an over precise USD amount rounded up to amount decimals plus four and then back down. Get any of it wrong and the order is rejected. All of this is reimplementable, and Predictefy's own pipeline runs on the underlying HTTP rather than the SDK, though that pipeline reads prices and never signs an order, which is most of the difference between our situation and yours. Reproducing the write path is a week of work to rebuild something the exchange already maintains. One more wrinkle: the address that signs is not necessarily the address holding the money, which is why the client exposes signer and wallet as separate fields. Our Polymarket API guide covers the auth model in full.

The First Call, Annotated

The read path takes no credentials at all, which is the cleanest demonstration of where the auth boundary sits. This is the package's own quickstart:

from polymarket import Market, PublicClient

with PublicClient() as client:                      # no key, no wallet, no arguments
    market: Market = client.get_market(             # returns a typed model, not a dict
        url="https://polymarket.com/event/example-market"
    )

PublicClient() takes zero arguments, which is the type system telling you public endpoints need no auth, and get_market accepts an ordinary market URL, skipping the slug to condition ID to token ID walk that raw HTTP forces on you.

Writing uses a different constructor entirely, and the differences matter more than the extra line suggests:

import os
from polymarket import AsyncSecureClient

# inside an async function
client = await AsyncSecureClient.create(
    private_key=os.environ["POLYMARKET_PRIVATE_KEY"],  # environment, never source
    wallet="0x...",                                    # the funded address
)

The key comes from the environment. The client is async, so the write path drags await through whatever calls it. And wallet is separate from the signing key on purpose, matching the signer and wallet split above. Two behaviours to internalise before your first order: market orders default to fill and kill, so any unfilled remainder is cancelled rather than left resting, and the order response is not a position, because settlement happens asynchronously on chain. The order call itself, with parameters, is in our Polymarket API Python tutorial.

The TypeScript Side

The Polymarket TypeScript SDK is @polymarket/client, MIT licensed, and it mirrors the Python surface closely enough that porting is mechanical. Same two clients, same split between an argument free read client and a write client that wants a signer:

import { createPublicClient, createSecureClient } from "@polymarket/client";

const publicClient = createPublicClient();              // no key, no wallet, no arguments
const secureClient = createSecureClient({ wallet, signer });   // signer comes from your adapter

Wallet libraries are optional peer dependencies, not requirements, so you install whichever signer your stack already uses: the package ships adapter subpaths for ./viem, ./ethers-v5 and ./privy, alongside ./node. Polymarket's own quickstart happens to use viem. The archived @polymarket/clob-client carries no npm deprecation flag, so installing it produces no warning at all. Silence at install, failure at runtime, which is the worst possible ordering.

When You Do Not Need a Client Library

If you only read, you may not need a Polymarket API wrapper. The public endpoints return plain JSON over ordinary HTTP with no key and no signing, and Polymarket is more open here than its main competitor, since Kalshi requires authentication even on its order book endpoint. For a price poller or a research dataset, requests and a JSON parse is a smaller dependency than a 0.x library that reserves the right to break on a minor release.

Placing orders inverts that. Roll your own and you own the EIP-712 structs, the HMAC, the contract selection, the rounding and every future protocol change. The April 2026 cutover is a fair warning about how those land: the order struct lost nonce, feeRateBps and taker, gained timestamp, metadata and builder, open orders were wiped, and pUSD replaced USDC.e as collateral in the same window. Fees now apply at match time rather than being signed into the order, so do not hardcode a rate; our Polymarket fees breakdown covers what is actually charged, and our trading bot guide starts where this page ends. Polymarket US, meanwhile, is a separate regulated exchange with its own polymarket-us SDK and entirely different Ed25519 credentials. None of this is financial, tax or legal advice.

Frequently Asked Questions

Conclusion

The install line is short and the reasoning behind it is the useful part: polymarket-client or @polymarket/client, pinned exactly, on Python 3.11 or node 24, with anything named clob-client left where you found it. Judge these packages by their publisher and their last commit rather than their star counts, because the stars belong to a library that cannot place an order. If you want the raw HTTP underneath, our Polymarket API Python tutorial walks the endpoints directly.