1.5TB Limitless Historical Data via Assymetrix for Devs & Quants

Limitless historical data is available through native venue endpoints and CCXT’s limitless exchange interface, but raw access alone will not get you cross-venue research. Native endpoints return slug-scoped, preset-interval series that vary in field naming and retention. For research spanning Limitless, Polymarket, and Kalshi, you need a normalized layer like the Assymetrix Data API, which assigns canonical IDs and a consistent schema across venues.

TL;DR:

• Native Limitless endpoints use preset intervals and differ in data structure, making cross-venue normalization difficult without a unifying schema.

• The Assymetrix Data API provides a consistent, normalized dataset with canonical IDs, covering nearly 900 million events since 2020 to simplify cross-venue research.

• Reconciliation issues such as slug mismatches, timestamp inconsistencies, AMM fallback distortions, and coverage gaps are eliminated through this normalized API.

• For baseline analysis, public oracle-candles and historical-price endpoints are recommended, with authenticated logs added only when detailed trade data is required.

• Cross-venue applications like arbitrage detection and smart money tracking become straightforward once data is unified under the same schema.

AssymetrixQuery Unified Market DataAssymetrix brings Limitless, Polymarket, and Kalshi data together through one normalized intelligence layer for research and development.Explore Assymetrix

Table of Contents

• What Limitless Historical Data Actually Contains

• Native Access: CCXT Methods and REST Endpoints

• Why Native Limitless Data Resists Easy Normalization

• Normalized Limitless Data Through the Assymetrix Data API

• Building an Integration Pipeline Step by Step

• Cross-Venue Signals Worth Building

• Keeping Research Reproducible Over Time

• What Integrating Limitless Data Actually Teaches You

• Start Querying Normalized Limitless Data Today

• Sources

• FAQ

What Limitless Historical Data Actually Contains

Limitless is a prediction market venue distinct from Polymarket and Kalshi in one key structural way. many of its markets run on short-lived, recurring cycles rather than long-duration single contracts. That shapes every dataset you will pull.

A given market exposes a handful of record types: YES/NO price series, individual trade fills, settlement events, and, for markets wired to Chainlink Data Streams, oracle candlestick data tracking the underlying reference price. Wallet-level activity exists but is gated behind authenticated endpoints rather than public history.

The market structure itself adds complexity. Limitless runs both AMM-priced markets and CLOB-style order books, and many products spin up as hourly or 15-minute recurring instances grouped under a parent slug. Reconstructing a longer series often means querying multiple child markets and stitching them chronologically rather than pulling one continuous feed.

Interval handling is preset-based, not arbitrary:

• Lookback windows come from fixed presets: 5m, 1h, 6h, 1d, 1w, 1m, and all.

• all returns the market’s entire lifespan, clipped to its actual start and resolution.

• Each preset carries its own bucket limit, so higher-resolution requests cover shorter windows.

Native Access: CCXT Methods and REST Endpoints

CCXT ships a dedicated limitless exchange interface, which is the fastest entry point if you already work in a CCXT-based stack. The core methods are fetchMarkets, fetchTrades, fetchOHLCV, fetchTickers, and fetchEvents. fetchOHLCV maps outcome prices into standard OHLCV arrays: timestamp, open, high, low, close, volume, scoped to a specific outcome and timeframe.

If you prefer REST directly, two endpoints do most of the work:

• /markets/{slug}/historical-price returns price history using the interval presets above, with parameters for interval, since, limit, and outcome.

• /markets/{addressOrSlug}/oracle-candles returns Chainlink-sourced OHLCV candles for the underlying reference asset, separate from the prediction market’s own price.

Practical limits matter here. Bucket counts cap how far back a single call reaches at high resolution, all lookback still respects per-market lifespan, and AMM buckets with no trade activity return a synthesized 0.5 fallback rather than a null. Caching windows on the public endpoints are generous, which helps, but you are still bound by fixed presets rather than custom date ranges.

Why Native Limitless Data Resists Easy Normalization

Four issues consistently trip up anyone building a research pipeline directly on native Limitless endpoints.

The first is identity. Markets are addressed by slug, but group markets and their child instances scope differently, so a slug that looks stable in one query can point to a different child market in another. Without a canonical ID layer, deduplication and cross-market joins become manual work.

The second is timestamps. Different endpoints encode time differently, and retention windows are not uniform across market types, so a series pulled today may not match the same query run next week if the underlying market has aged out of its live bucket.

The third is the AMM fallback problem. AMM buckets without trades synthesize a 0.5 value instead of returning an empty point, which quietly distorts volatility and spread calculations if you don’t flag and exclude those buckets.

The fourth is coverage gaps. There is no centralized archive: field names shift between endpoints, and fill-level trade and wallet data sit behind authenticated access, so any pipeline mixing public and private sources needs separate auth handling and separate retry logic.

Normalized Limitless Data Through the Assymetrix Data API

The Assymetrix Data API exists specifically to remove the four problems above. It aggregates Limitless alongside Polymarket and Kalshi under one schema, so a query against Limitless history returns the same field structure as a query against either other venue.

That normalization rests on a few concrete pieces:

• Canonical event IDs that persist across slug changes and group/child market restructuring, which is the single most valuable artifact for cross-venue matching.

• A consistent schema for price series, trades, and settlement events, regardless of which venue originated the record.

• Coverage at scale: roughly 1.5 terabytes of historical data spanning close to 900 million indexed events across venues since September 2020

• Published backtesting work covering over 200 million price snapshots, which stress-tests the normalization against real reconciliation problems rather than synthetic data.

• Delivery through REST, bulk export, and streaming, with support tiers scaled for individual researchers up through institutional data consumers.

For a developer who has already fought with slug mismatches or AMM fallback noise, the difference is mostly what you stop having to build yourself: dedup logic, timestamp reconciliation, and multi-auth handling all collapse into one integration.

Building an Integration Pipeline Step by Step

A working pattern for pulling and validating Limitless historical series looks like this:

1. Start with public oracle-candles or historical-price endpoints for baseline OHLCV. These are cache-friendly and don’t require key management, so lean on them for exploratory work and initial charting.

2. Expand any group slug into its child markets, then stitch the resulting series by timestamp, normalizing every value to epoch milliseconds before merging.

3. Add authenticated trade logs only when you need fill-level reconstruction (Smart Money wallet tracking, precise entry/exit pricing) rather than for routine charting.

4. Validate the merged series against a snapshot or checksum, store canonical event IDs alongside the raw response, and explicitly flag any AMM fallback points before running volatility calculations.

Pro Tip: Reach for oracle-candles before authenticated logs whenever you’re doing baseline charting or low-cost backtests. Public endpoints are cache-friendly and skip the rate-limit and key-management overhead that authenticated fill data carries.

Developers working in Python can shortcut steps 1 through 3 with the patterns in the Python on prediction market data guide, which covers client setup for normalized cross-venue queries.

Cross-Venue Signals Worth Building

Once Limitless history sits on the same schema as Polymarket and Kalshi, several research and trading patterns become straightforward to run at scale.

• Arbitrage detection: match markets by canonical ID across venues, then measure spread persistence with latency awareness, since a gap that closes in under a second is a different signal than one that holds for minutes.

• Smart Money tracking: link wallet activity across venues to build leaderboards and skill scores, surfacing traders whose entries consistently precede price moves.

• Backtesting: reconstruct unified price snapshots and event-level trade records to compute strategy profit-and-loss without re-deriving venue-specific quirks each time.

• AI agent training: clean, deduplicated snapshots matter more than raw volume, since an agent trained on AMM fallback noise will learn a distorted volatility profile.

Guides on prediction market arbitrage and cross-venue price gaps walk through the measurement mechanics behind the first two use cases in more detail. For real-time spread monitoring across venues, tools like the ones covered in real-time trade analysis platforms can complement a normalized data layer once the underlying records are clean.

Keeping Research Reproducible Over Time

Reproducibility fails quietly if you skip a few operational habits.

• Keep a persistent canonical ID mapping table and store raw-response snapshots alongside processed data for reconciliation.

• Normalize every timestamp to epoch milliseconds and document your timezone convention once, then never deviate from it.

• Exclude AMM fallback buckets from volatility or spread math unless a trade log corroborates the price.

• Cache public endpoints aggressively and design backfills around bucket limits rather than fighting them with retries.

Pro Tip: Log every transform you apply and checksum each dataset version. When a Limitless series looks different a month later, a checksum tells you in seconds whether the venue changed the data or your pipeline did.

What Integrating Limitless Data Actually Teaches You

Every pitfall in this guide traces back to one root cause: Limitless was built for market operation, not for downstream research. The pattern that saves the most time is oracle-first sourcing paired with strict canonical ID discipline from day one.

Teams that build this in-house typically spend weeks on reconciliation logic before writing a single backtest. Outsourcing that layer to a normalized API turns weeks into a single integration call.

— Dean

Start Querying Normalized Limitless Data Today

Native Limitless endpoints and CCXT give you a working start, but they leave the reconciliation work (slug matching, timestamp normalization, AMM fallback handling) entirely on your plate. The Assymetrix Data API removes that work by delivering Limitless history on the same canonical schema as Polymarket and Kalshi, so a single integration replaces three separate parsers and a manual ID-matching layer.

If you’re building a bot, an AI agent, or a backtesting pipeline that needs clean cross-venue history rather than three inconsistent feeds, start with the Prediction Market Data Feed API guide to see the schema and available endpoints. Developer and free tiers are available for testing queries, and commercial and institutional tiers cover bulk export and higher throughput. Read the docs, run a sample query against Limitless history, and reach out for a commercial quote once your pipeline needs production volume.

FAQ

Does Limitless Have a Public Historical Data API?

Yes. Limitless exposes /markets/{slug}/historical-price and /markets/{addressOrSlug}/oracle-candles, plus a CCXT limitless exchange interface with methods like fetchOHLCV and fetchTrades.

Why Is Limitless Historical Data Hard to Normalize?

Slug-based identifiers don’t map cleanly to canonical market IDs across group and child markets, timestamp and retention formats vary by endpoint, and AMM buckets without trades return a synthesized 0.5 value instead of a true gap.

Can I Get Limitless, Polymarket, and Kalshi Data From One API?

Yes. The Assymetrix Data API aggregates all three venues under one normalized schema with canonical IDs, covering a very large volume of data across hundreds of millions of indexed events since September 2020.

What’s the Difference Between Historical-Price and Oracle-Candles Endpoints?

historical-price returns the prediction market’s own outcome price series, while oracle-candles returns Chainlink-sourced OHLCV data for the underlying reference asset on markets configured with Chainlink Data Streams.

How Do I Detect Arbitrage Across Limitless, Polymarket, and Kalshi?

Match markets by canonical ID across venues, then measure price-spread persistence with latency awareness. A unified schema makes this comparison direct instead of requiring three separate parsers.