Skip to main content
New here? Start with Quickstart (read-only, 30 seconds) or Trading Quickstart (hosted writes, 5 minutes).
PMXT is a unified API for supported prediction-market venues — Polymarket, Kalshi, Limitless, Smarkets, and 12 more venues. It uses shared SDK method names and unified response shapes where each venue supports the underlying capability.
New to prediction markets? Start at the 101 page for the vocabulary — outcome, price-as-probability, EIP-712, escrow, USDC on Polygon, and Group A methods.
It runs two ways:
  • Hosted (default) — PMXT’s hosts give you a shared catalog, cross-venue search, and end-to-end hosted trading with PreFundedEscrow custody. Set an API key and the SDK is fully operational.
  • Self-hosted (advanced) — for users who run pmxt-core on their own machine. No API key, no external dependency. Your requests go directly to the venues. See self-hosted.
The SDK call shape is shared, but the runtime target changes:
If you’d rather run pmxt-core yourself, drop the API key:
Hosted mode uses a PMXT API key and hosted services. Self-hosted mode talks to local pmxt-core and uses venue-native credentials where a capability requires them. See self-hosted for when that’s the right choice. Swap the venue class — pmxt.Kalshi(...), pmxt.Limitless(...) — and use the same method names and response shapes where that venue implements the capability.

The Router — cross-venue intelligence

The Router is PMXT’s cross-venue intelligence layer. Search, match, and compare prices across the hosted catalog — all from a single PMXT API key:

Cross-venue search

One query searches the hosted catalog. Results in ~10ms from a shared index.

Market matching

Find clusters of the same or related market across venues with relation types and confidence scores.

Price comparison

Compare bid/ask across venues and find related markets.

Compose with venues

Discover with the Router, then trade with venue clients. Same schema; catalog IDs for Router and hosted flows, venue-native IDs for direct self-hosted writes.

Unified venue interface

Same method names, same response shapes, with support varying by venue. fetch_markets, create_order, and fetch_positions use the unified schema where the venue implements them.

Unified schema

Event / Market / Outcome — the shape that works everywhere.

Same SDK, local or hosted

The pmxt (Python) and pmxtjs (TypeScript) SDKs share high-level calls across hosted and self-hosted modes. Credentials and supported writes vary by mode.

What you’d build yourself

Without PMXT, getting cross-venue prediction market data means:
  • 15+ venue integrations — each with its own auth, pagination, field names, and rate limits. Polymarket uses CLOB token IDs. Kalshi uses tickers. Smarkets uses contract IDs. You normalize all of it.
  • A data pipeline — to ingest, deduplicate, and keep fresh as markets open, resolve, and re-price across supported venues.
  • A search layer — because querying venue APIs sequentially is slow.
  • Ongoing maintenance — every time a venue changes a field name or ships a new endpoint, your integration breaks.
PMXT handles all of that. You write fetch_markets(query="...") and get back clean, unified data.

Get started

Quickstart

API key to working code in 30 seconds.

Router

Cross-venue search and the beginning of smart order routing.

Unified schema

The data shape that works everywhere.

API reference

Every method, with interactive try-it-out.