Migrating from another provider

If you’ve already built against another data source or run your own indexer, this page maps your existing patterns to Predexon. Most migrations are a one-line URL change.

From Polymarket’s native API (CLOB / Gamma)

Polymarket publishes a CLOB API for orderbook data and a Gamma API for market metadata. Both are useful; both have rough edges (rate limits, missing fields, inconsistent shapes across venues if you also use Kalshi etc.).

Polymarket native	Predexon equivalent	Notes
`GET https://gamma-api.polymarket.com/markets`	`GET /v2/polymarket/markets`	Same filters, richer response, free + unlimited
`GET https://clob.polymarket.com/markets/{condition_id}`	`GET /v2/polymarket/markets?condition_id={...}`	Same data, normalized shape
`GET https://clob.polymarket.com/book?token_id={...}`	`GET /v2/polymarket/orderbooks?token_id={...}`	Predexon also gives you history — Polymarket native is current-only
`GET https://clob.polymarket.com/trades?market={...}`	`GET /v2/polymarket/trades?token_id={...}`	Predexon supports cursor pagination + multi-market filters
`GET https://gamma-api.polymarket.com/events`	`GET /v2/polymarket/events`	Same
WebSocket: `wss://ws-subscriptions-clob.polymarket.com/...`	`wss://wss.predexon.com/v1/{key}`	Same channels, normalized payloads, plus pending-trade detection
(No native equivalent)	`GET /v2/polymarket/wallet/pnl/{wallet}`, smart-money, leaderboards	Net-new capability

Migration shape: usually one search-replace on base URLs. Response shapes are a strict superset — your existing parsers keep working. Add the x-api-key header and you’re done.

- url = "https://gamma-api.polymarket.com/markets"
+ url = "https://api.predexon.com/v2/polymarket/markets"
- headers = {}
+ headers = {"x-api-key": os.environ["PREDEXON_API_KEY"]}

From Dune

Dune is great for ad-hoc SQL; Predexon is built for application-time queries with consistent latency.

Dune query type	Predexon equivalent	Why switch
`polymarket.trades` table queries	`/v2/polymarket/trades`	`<200ms` vs minutes for Dune query execution
`polymarket.positions` aggregations	`/v2/polymarket/wallet/positions/{wallet}`	Pre-computed, ready-to-render
Wallet leaderboards	`/v2/polymarket/leaderboard`	Same query, cached and live
Cross-venue joins	`/v2/matching-markets`	LLM-curated; Dune SQL can’t match titles reliably

Dune still wins for exploratory work and one-off custom aggregations. Predexon wins for anything in your hot application path. Often the right pattern is: prototype the analysis in Dune, then port to Predexon for production.

From Goldsky / The Graph / a self-built subgraph

If you’re running a Polymarket subgraph or other indexed source, the question isn’t whether yours works — it’s whether the maintenance burden is invisible until it breaks. Self-indexers fail quietly. You discover the gap when a reorg drops events, when a contract upgrade silently changes a field, when your node falls behind and your dashboard is showing stale prices.

Self-indexed pain point	What Predexon gives you
Reorg handling, missed events	We handle on-chain reorgs and replay
Multi-venue indexing	One API across 7 venues; you maintain 0 indexers
Smart-money / leaderboard / matching	Pre-computed analytics layers
Pending-trade detection	Native — requires a co-located Polygon node otherwise
On-call burden	Zero — we run the infra
Cost	Free tier covers most workloads; Pro is $249/mo

The engineering ROI math: a single engineer-hour at most companies costs

100–200 loaded. If your team is putting 5h/month into indexer maintenance and on-call (and most do — it's just that the cost is hidden in your engineers' headers), that's

6k–24k/year. Pro tier (

249/mo =

3k/year) pays for itself even if the only thing it eliminates is your on-call rotation. And if a subgraph outage costs you a degraded trading day, the cost gap is much bigger than that. If you genuinely enjoy maintaining the subgraph, keep it. If “the subgraph works fine” actually means “nobody’s looked at it in 3 months and I hope nothing has drifted,” migrate.

From a custom Polygon indexer

You probably built this because you needed:

Sub-second confirmed-trade latency → WebSocket trades channel is the same data, no node to run
Mempool / pending-trade detection → WebSocket pending-trades gives you exactly this
Cost basis / P&L reconstruction → Wallet P&L is pre-computed
Cross-venue equivalence → Matched Pairs is LLM-curated

The hardest indexer pattern to replicate is wildcard firehose for niche tokens. Predexon offers wildcard subscriptions on Pro (2 per channel) which covers most use cases. If you need every Polygon log for custom analysis, you’ll still want your own node — but use Predexon for everything else and save the node for the 10% it actually adds.

From Kalshi’s native API

Kalshi native	Predexon equivalent	Notes
`GET /trade-api/v2/markets`	`GET /v2/kalshi/markets`	Same data, no Kalshi auth required (we proxy)
`GET /trade-api/v2/markets/{ticker}/trades`	`GET /v2/kalshi/trades?ticker={...}`	Historical trade tape
`GET /trade-api/v2/markets/{ticker}/orderbook`	`GET /v2/kalshi/orderbooks`	Historical snapshots

Kalshi trading is not yet supported via Predexon. Use Kalshi’s native API for execution; use Predexon for data.

From building your own trading wallet stack

If you’ve built (or are about to build) custody for Polymarket / Predict / Limitless trading, the migration is bigger but the engineering savings are enormous. Stop building:

Per-venue wallet generation, key storage, signing infrastructure
Per-chain funding / withdraw flows
Cross-chain bridging integration (Across, etc.)
Per-venue order signing (Polymarket EIP-712, Predict signature, Hyperliquid HIP-4)
Settlement and redemption flows

Start using: the Trading API — single account, every venue, Turnkey-managed keys, unified order shape, partner fee monetization. See the Builder Architecture Guide for the full architectural pattern.

Migration checklist

Get a Predexon key and validate the response shapes you depend on

The Quickstart gets you running in 5 min. Diff one of your real queries against the Predexon equivalent to confirm fields match.

Port one endpoint at a time

Don’t big-bang the migration. Replace one endpoint, ship, verify metrics. Repeat.

Add caching and retries while you're in there

See Best Practices. Caching is usually a 10x rate-limit relief on day one.

Switch to WebSocket for anything you're polling under 30s

If you were polling Polymarket’s CLOB every second, the equivalent WebSocket subscription is cheaper and faster.

Decommission the indexer / proxies you replaced

The point is to delete code, not accumulate it.

Need a translation that’s not here?

We’ve helped teams migrate from a dozen different stacks. If you’re stuck on a specific query or shape, drop into Discord — fastest answers there.

Documentation Index

​From Polymarket’s native API (CLOB / Gamma)

​From Dune

​From Goldsky / The Graph / a self-built subgraph

​From a custom Polygon indexer

​From Kalshi’s native API

​From building your own trading wallet stack

​Migration checklist

​Need a translation that’s not here?