Nearly 1B Rows of Normalized Prediction Market Resolution Data for Developers

Pull canonical resolution data through a prediction-market data API or a normalized cross-venue feed, not by scraping venue UIs or trusting cached price pages. At minimum, your backtest or training pipeline needs four fields per event: the resolved outcome, the resolution timestamp in UTC, the resolution source, and the settlement value. Venue-native APIs like Polymarket and Kalshi expose these fields in incompatible formats, which is why most quant teams route through a normalized provider like Assymetrix instead of building three separate parsers.

TL;DR:

• Normalized resolution data from APIs like Assymetrix ensures consistent, schema-verified outcomes across venues, handling differences in payout units and outcome definitions.

• Reliable backtests require seven fields per event, including a resolution timestamp in UTC, settlement value, source, and outcome, to prevent contamination and facilitate accurate evaluation.

• Streaming APIs via WebSocket offer near-instant resolution event delivery, while REST APIs are suitable for retrospective backfill and historical data collection.

• Validation rules should enforce timestamp monotonicity, outcome invariants, and conflict handling to catch late corrections, ambiguous resolutions, or missing data fields.

• Commercial API access typically involves custom pricing, SLAs for uptime and resolution lag, and support features like dedicated contacts and outage alerts, critical for production trading systems.

AssymetrixBuild With Unified Market DataAccess structured prediction market data across Polymarket, Kalshi, and Limitless through one Data API integration.Explore the Data API

Table of Contents

• What Resolution Data Contains and Why It’s Ground Truth for Backtests

• How Do Prediction Market APIs Structure Resolution Endpoints?

• What Authentication and Rate-Limit Patterns Should You Expect?

• Normalizing Resolution Data Across Polymarket, Kalshi, and Other Venues

• Building an Ingestion Pipeline: REST Backfill and WebSocket Live Feeds

• What Data Do You Need for Execution-Realistic Replay Backtests?

• Common Pitfalls and Validation Checks for Settlement Feeds

• Assymetrix Data API: Normalized Resolution Data Across Venues

• What Do Resolution Data APIs Cost, and What Do Access Tiers Include?

• How Fast Does Resolution Data Update After a Market Closes?

• What Licensing and Usage Restrictions Apply to Resolution Data?

• What Support and SLA Options Exist for Commercial API Users?

• Engineering Trade-Offs When Relying on Resolution Data in Production

• Getting Started With the Assymetrix Data API

• Sources

• FAQ

What Resolution Data Contains and Why It’s Ground Truth for Backtests

Resolution data is the settlement record of a prediction market: the moment an event contract stops trading and pays out based on a real-world outcome. It differs from price data in one critical way. Price data reflects belief. Resolution data reflects fact, locked in after the event window closes.

A complete resolution record needs seven fields to be usable in a backtest or a training set:

• event_id — the canonical identifier for the underlying real-world event, independent of venue.

• market_id — the specific tradable contract tied to that event (a single event can spawn multiple markets, especially for multi-outcome elections or sports brackets).

• resolved_outcome — typically YES/NO for binary contracts, or an enum value for multi-outcome markets.

• settlement_value — the payout basis, usually 1 or 0 for binary contracts, sometimes a dollar figure for scalar markets.

• resolution_timestamp — the UTC time the outcome became final, not when the event itself occurred.

• resolution_source — the oracle, data feed, or manual review process that determined the outcome.

• resolution_criteria — the original text defining what counts as a YES resolution, critical for auditing edge cases after the fact.

This structure is why resolution data makes uniquely clean training ground truth for machine learning. Unlike news text or social sentiment, a resolution timestamp is unambiguous. A market either paid out YES at a specific second or it didn’t, which sidesteps the biggest problem in financial ML: pre-training contamination, where a model has already seen the outcome baked into internet text before you evaluate it. PolyBench built its entire evaluation design around this property, pairing 38,666 binary market snapshots across 4,997 events with synchronized order book states and contemporaneous news streams specifically to keep evaluation contamination-proof.

Edge cases complicate the clean picture. Conditional markets (“resolves YES only if Market B also resolves YES”) carry dependency logic that a flat resolved_outcome field can’t express alone. Split resolutions, common in multi-candidate election markets, distribute partial settlement across several outcome buckets rather than a single winner. Rolling resolutions, seen in recurring economic-data markets, resolve on a schedule rather than a single terminal event. Each case needs its own handling logic before it enters a training set, or your model learns from an oversimplified signal.

How Do Prediction Market APIs Structure Resolution Endpoints?

Most venue and provider APIs expose resolution data through a small, predictable set of endpoints. The naming varies, but the pattern is consistent across the space:

• /events — returns event-level metadata, often the parent of several markets.

• /markets — returns individual contract details, including current status (open, closed, resolved).

• /markets/{id}/settlement — returns the terminal settlement record for a specific market once resolved.

• /resolutions — a feed-style endpoint for querying resolved markets over a date range.

• /settlements/bulk — bulk export endpoint for historical backfill, usually paginated or chunked by date.

A settlement object returned from these endpoints typically looks like this:

Streaming versus polling depends on what your system needs to do with the data. If you’re running a live trading bot that reacts to settlement events within seconds, a WebSocket subscription to a settlement or resolution channel beats REST polling every time. It gives you push-based delivery the instant a market closes, rather than discovering it on your next poll cycle. If you’re backfilling five years of resolved markets for a training set, REST with cursor-based pagination is the right tool. Bulk export endpoints matter here: pulling a settlement feed one market at a time across tens of thousands of historical events is a good way to hit rate limits and burn a week doing what a single bulk export job does overnight.

A practical rule: use REST for anything retrospective, WebSocket for anything you need to act on in real time, and never mix the two for the same ingestion job. Trying to reconcile a REST backfill running concurrently with a live WebSocket feed on the same table is where duplicate-row bugs come from.

What Authentication and Rate-Limit Patterns Should You Expect?

Prediction market APIs generally use one of three authentication patterns, and picking the wrong one for your use case creates operational pain later. API key headers work fine for server-side batch jobs and backfill scripts, where a single long-lived credential moving through a private backend poses low risk. OAuth2 client credentials suit multi-tenant applications where different users or teams need scoped, revocable access. Signed tokens, refreshed periodically, are standard for WebSocket connections where the handshake needs to prove identity without re-sending a static key on every message.

Follow these steps to build an ingestion layer that survives production traffic:

1. Rotate API keys on a schedule, not just after a suspected leak, and scope each key to the minimum endpoint set it needs.

2. Implement a token bucket for REST calls rather than a fixed sleep timer. It absorbs bursts without wasting quota during quiet periods.

3. Use exponential backoff with jitter on 429 and 5xx responses, capping retries so a stalled venue doesn’t spiral your job into a retry storm.

4. Add a circuit breaker that halts a feed integration after repeated failures, alerting a human instead of silently dropping data.

5. Cap concurrent connections per venue explicitly. Prediction market APIs are smaller operations than major exchange infrastructure, and aggressive concurrency gets you throttled or blocked.

6. Track sequence numbers or event versions on every settlement write, so a replayed or out-of-order message never overwrites a newer record with a stale one.

Pro Tip: Store a replay token or last-processed cursor for every feed connection, separate from your application logs. When a WebSocket disconnects mid-session, that cursor is what lets you resume exactly where you left off instead of re-ingesting a full day’s settlements and creating duplicate rows.

Normalizing Resolution Data Across Polymarket, Kalshi, and Other Venues

Cross-venue normalization is where most in-house resolution pipelines quietly break. Polymarket and Kalshi structure their resolution data around fundamentally different assumptions, and neither is wrong. They’re just built for different regulatory and product contexts.

The differences show up in three consistent places:

• Settlement units — Polymarket settles in dollar-denominated payout per share on-chain; Kalshi settles regulated binary contracts with a fixed payout structure tied to CFTC-compliant rules.

• Conditional and forced-split logic — multi-outcome events handle partial resolution differently depending on venue-specific market design, especially around disputed or ambiguous outcomes.

• Resolution source multiplicity — a single event can have more than one reported resolution timestamp if a venue issues a correction after an initial (sometimes premature) settlement call.

A working normalization recipe holds up across these differences if you build it around four rules. First, map every venue-native outcome into one canonical enum (YES, NO, or a defined multi-outcome set) rather than preserving each venue’s raw label. Second, convert every resolution_timestamp to UTC at ingestion, never at query time, so downstream joins don’t silently misalign across time zones. Third, tag every record with a resolution_source field that names the originating venue and oracle, keeping that provenance separate from the canonical event and market IDs rather than baking a vendor prefix into the ID itself. Fourth, when two venues report conflicting resolution data for economically linked events (rare, but it happens around ambiguous real-world outcomes), prefer the official exchange settlement record over a secondary aggregator, and log the conflict rather than silently overwriting one value with another.

That reconciliation log matters more than it sounds like it should. When an auditor, a research partner, or your own future self asks why a backtest produced a different result after a data refresh, a provenance trail is the difference between a five-minute explanation and a week spent reconstructing what happened.

Building an Ingestion Pipeline: REST Backfill and WebSocket Live Feeds

A production-grade resolution data pipeline needs two distinct ingestion paths that share a validation layer but run independently.

For historical backfill, follow this sequence:

1. Paginate by date range, not by offset, since offset-based pagination breaks when new markets resolve mid-backfill and shift your result set.

2. Batch requests at a rate-limit-aware size, typically 100 to 500 records per call depending on the provider’s documented ceiling.

3. Validate schema before insert, checking that resolved_outcome, resolution_timestamp, and settlement_value are all present and typed correctly before a row ever touches your database.

4. Deduplicate on a composite key of market_id plus resolution_timestamp, since a corrected resolution will arrive as a near-duplicate record with an updated value.

For live WebSocket ingestion, the sequence looks different:

1. Connect and authenticate using a signed, time-limited token rather than a static key sent in the open.

2. Subscribe explicitly to settlement or resolution channels, not a general market-data firehouse, to avoid processing thousands of irrelevant price ticks.

3. Acknowledge messages and respond to heartbeats to keep the connection alive; a missed heartbeat response is the most common cause of silent disconnects.

4. Write settlement events durably before acknowledging them, so a crash between receipt and disk write doesn’t lose a resolution record permanently.

A short production checklist keeps both paths honest: every record needs a deduplication key, every market_id needs a canonical mapping back to your internal schema, every batch needs a validation test before it’s considered ingested, and every historical dataset needs to be fully replayable from raw storage in case you need to rebuild a table after a schema change. Skipping that last point is a common mistake. Teams that only store the processed output, not the raw settlement payloads, discover they can’t fix a normalization bug retroactively without re-pulling months of history.

What Data Do You Need for Execution-Realistic Replay Backtests?

Reliable backtesting on prediction markets needs more than a resolved_outcome column. It needs the full episode artifact set that lets you replay a market exactly as it traded, then check the final settlement against what your strategy would have done in real time.

The minimum artifact bundle includes:

• settlement.json — the final resolved outcome and settlement value for the episode, the ground truth your simulated trades get scored against.

• trades.parquet — every trade print during the market’s active window, with timestamps and prices.

• orderbook.parquet or snapshots — book state at intervals fine enough to model realistic fills, not just closing prices.

• metadata.json — episode configuration: market rules, contract type, resolution criteria text, and venue identifiers.

• A fee model — maker and taker fee schedules applied to simulated fills, since ignoring fees routinely inflates back tested returns.

Two published benchmarks are worth studying directly rather than reinventing the format yourself. PredictionMarketBench structures its episodes around exactly this artifact set, metadata.json, orderbook.parquet, trades.parquet, and settlement.json, to make experiments portable and deterministic across research teams. PolyBench takes a similar approach but adds synchronized news-stream data alongside order book snapshots, which matters if your strategy incorporates any text-based signal.

Simulation quality hinges on details that are easy to skip. Fee-aware fills change reported returns significantly; PredictionMarketBench’s own modeling shows maker fees running well below taker fees, meaning a strategy that assumes it always gets maker pricing will look far more profitable in backtest than it would in live trading. Maker/taker fill probability modeling, strict timestamp ordering across trades and order book updates, and a hard cutoff enforcement that prevents any post-settlement information from leaking into your feature set are the three pillars that separate a credible backtest from an optimistic one. Hindcast enforces this cutoff at the row level, guaranteeing every document a model retrieves during evaluation was created before the simulated decision point, which is the same discipline your own replay harness needs if you want results that hold up out of sample.

Common Pitfalls and Validation Checks for Settlement Feeds

Five failure modes account for most of the bad data quietly sitting in resolution datasets:

1. Late corrections — a venue resolves a market, then issues a correction hours or days later after a dispute review, leaving stale data in any pipeline that doesn’t re-check resolved markets.

2. Ambiguous or forced 50/50 resolutions — some conditional markets resolve to a split payout when the underlying condition can’t be cleanly determined, and treating that as a normal binary outcome corrupts training labels.

3. Missing settlement_value fields — surprisingly common in venue APIs, where resolved_outcome populates but the numeric payout field is left null.

4. Timezone errors — a resolution_timestamp stored in local venue time rather than UTC will silently misalign with any other data source in the same pipeline.

5. Conflicting venue reports — rare, but real, when secondary aggregators post a resolution before the official exchange settlement record is finalized.

Catch these with validation rules run automatically at ingestion, not manually after the fact:

1. Enforce monotonic timestamps per event so a later-arriving record can never claim an earlier resolution time than one already stored.

2. Check outcome invariants — a binary market’s settlement_value should only ever be 1.0 or 0.0, never an unhandled null or out-of-range float.

3. Run count reconciliations comparing the number of resolved markets your pipeline recorded against the venue’s own resolved-market count for the same date range.

4. Run daily checksum audits against a snapshot of the previous day’s settlement table to catch silent overwrites.

Operational monitoring closes the loop. Set SLA alerts for resolution lag, the gap between when an event concludes and when your pipeline records the settlement, since a growing lag usually signals an upstream API issue before it becomes a data-quality issue. Build automatic replay triggers that reprocess a market when a correction lands. Reconciliation dashboards that flag venue-reported counts against your own stored counts catch drift faster than any manual review process. Prediction Arena’s evaluation framework recommends this kind of reconciliation discipline as a baseline operational practice, not an optional add-on.

Pro Tip: Run your checksum audit against yesterday’s data, not today’s. Same-day audits catch nothing useful because a meaningful share of settlements still have open dispute windows.

Assymetrix Data API: Normalized Resolution Data Across Venues

Assymetrix’s Data API exists to remove the normalization work described above. Rather than building separate parsers for Polymarket’s on-chain settlement format and Kalshi’s regulated contract structure, the API returns resolution records in one consistent schema, with canonical event and market IDs and a tagged resolution_source field on every record.

What the feed covers:

• Cross-venue normalized resolution data spanning Polymarket, Kalshi, and Limitless through a single integration, drawn from a historical archive of roughly 1.5 terabytes and nearly one billion rows of trading activity.

• Multi-year historical backfill of resolved markets, letting research teams build training and backtest datasets without re-deriving settlement records from raw venue exports.

• A consistent outcome format across venues, so a YES/NO resolution from Polymarket and a settled contract from Kalshi arrive in your pipeline shaped the same way.

• A Python developer SDK for direct integration, alongside REST and WebSocket access for teams building real-time pipelines.

Teams working specifically with Polymarket’s on-chain resolution data can start at the dedicated Polymarket resource page, which covers the venue’s settlement structure in more depth. For a first integration, the practical sequence is straightforward: request an API key, run a sample settlement query against a small date range to confirm the schema matches your validation rules, then request a bulk historical export once you’re satisfied the normalized fields line up with what your backtest or training pipeline expects.

What Do Resolution Data APIs Cost, and What Do Access Tiers Include?

Pricing for prediction market resolution data APIs generally scales along three axes: how much historical depth you need, whether you require real-time streaming versus batch access, and whether you’re a non-commercial researcher or a commercial trading operation. Academic and non-commercial tiers typically offer limited historical windows or rate-capped access, sufficient for a research paper or a class project but not for production trading infrastructure.

Commercial tiers unlock the parts that matter for serious backtesting: full historical backfill rather than a rolling recent window, bulk export capability instead of record-by-record pulls, and often WebSocket access for live settlement events rather than REST-only polling. Institutional tiers add higher rate limits, dedicated support channels, and sometimes custom data delivery formats for teams integrating resolution data into existing quant infrastructure.

Assymetrix’s Data API doesn’t publish a fixed price list; access and pricing are handled on request through the Data API landing page. That’s a common pattern across the space, since usage volume, historical depth, and streaming needs vary enough between a solo researcher and an institutional desk that a one-size price rarely fits. If pricing transparency matters to your evaluation process, the practical move is to request a quote alongside a trial query against a small dataset, which tells you more about the actual schema quality than any pricing page ever will.

How Fast Does Resolution Data Update After a Market Closes?

Resolution data doesn’t arrive instantly, and the lag between event conclusion and confirmed settlement varies meaningfully by venue and by how the outcome gets determined. Markets resolved by an automated oracle feed, tied to a clear, verifiable data source like an official economic release, tend to settle within minutes of that source publishing. Markets resolved by manual review, common for more ambiguous real-world events, can take hours or occasionally days if a dispute window opens.

This matters directly for anyone building a live trading bot around resolution events: a system that assumes instant settlement will misjudge risk exposure on markets waiting for manual adjudication. It matters just as much for backtesting, where using a resolution timestamp that reflects when the outcome was first reported rather than when it was finalized introduces a subtle form of look ahead bias.

Update frequency for a normalized resolution feed depends on the ingestion method. Polling-based REST access typically refreshes on a fixed interval, often every few minutes, which is adequate for backfill and most research use cases. WebSocket-based streaming pushes settlement events the moment they’re recorded at the source, which matters for any system that needs to react to a resolution in near real time rather than discover it on the next poll cycle. Any resolution feed worth building a production system on should expose both options rather than forcing one ingestion pattern on every use case.

What Licensing and Usage Restrictions Apply to Resolution Data?

Licensing terms for prediction market resolution data typically split along two lines: how the data was sourced, and what you plan to do with it downstream. Data pulled directly from a venue’s public API generally carries the venue’s own terms of service, which often restrict redistribution, commercial resale, or high-frequency scraping beyond documented rate limits. Read those terms directly rather than assuming a public endpoint means unrestricted use.

Normalized data providers add a second licensing layer on top of the underlying venue terms. That typically distinguishes between non-commercial research use, which usually permits academic publication and model training without redistribution rights, and commercial licenses, which permit use inside a trading system, a commercial product, or a service you sell to others. The distinction matters most for teams building anything customer-facing: a trading bot you sell to clients, an AI agent product, or a dashboard you charge for almost always requires a commercial license rather than a research-tier agreement.

Before committing resolution data to a production model or a paid product, confirm three things with your provider: whether redistribution of raw records is permitted, whether derived outputs (model weights trained on the data, aggregated signals) carry separate restrictions from the raw data itself, and whether the license covers the specific venues your data spans. A license covering Polymarket data doesn’t automatically extend to Kalshi or Limitless data bundled into the same feed, and assuming otherwise is a common oversight that surfaces during a compliance review rather than during integration testing.

What Support and SLA Options Exist for Commercial API Users?

Support tiers for prediction market data APIs generally track the same commercial/non-commercial split as pricing. Free and academic tiers typically get community support, documentation, and best-effort response times, which works fine for a research project with flexible deadlines but poorly for anything running in production.

Commercial API users should expect, and should ask for explicitly, a defined SLA covering uptime guarantees, resolution-lag thresholds, and a documented incident response process for when a feed goes stale or a venue’s own API has an outage upstream. A resolution feed’s SLA matters more than a typical data API’s, because a delayed settlement update doesn’t just mean stale data; it can mean a trading system holding a position it should have closed the moment a market resolved.

Practical questions worth putting to any provider before signing a commercial agreement: what’s the guaranteed maximum resolution lag under the SLA, what’s the escalation path when a discrepancy appears between venue-reported and provider-reported settlement data, and does the support agreement include a dedicated technical contact or only a ticket queue. Institutional data consumers running capital against a resolution feed should also confirm whether the provider offers a status page or webhook alerting for feed degradation, since discovering an outage through a failed trade is the expensive way to find out.

Engineering Trade-Offs When Relying on Resolution Data in Production

Raw venue feeds work when you only need one venue and can tolerate building your own normalization layer. Everyone else benefits from a normalized provider. Prioritize canonical IDs and replay hooks over convenience features, since reproducibility is what lets you trust a backtest result months later. Watch resolution lag and reconcile constantly. A model is only as good as the settlement data it was scored against.

— Dean

Getting Started With the Assymetrix Data API

Normalized prediction market resolution data across multiple venues is available through a unified schema, with canonical IDs, tagged resolution sources, and multi-year historical backfill accessible via a single integration.

The Data API gives you REST, WebSocket, and a Python SDK built specifically for the ingestion patterns covered above: bulk historical backfill for training sets, live settlement streaming for production bots, and validated schemas so you’re not writing reconciliation logic from scratch. Institutional teams needing deeper historical coverage can review the 1.5TB backfill offering built for exactly this kind of research workload.

To get started, request an API key, run a sample settlement query against a narrow date range to confirm the normalized fields match your validation rules, then request an institutional backfill if your backtest needs multi-year depth. Start at Data to request access.

FAQ

What fields does prediction market resolution data include?

Resolution data includes the resolved outcome, a UTC resolution timestamp, the resolution source, and a settlement value, along with canonical event and market IDs. Some venues also expose the original resolution criteria text used to determine the outcome.

Why is resolution data better than price data for ML training?

Resolution data locks in as a verified binary or enum outcome only after an event window closes, which makes it contamination-proof ground truth rather than a belief signal that shifts constantly. PolyBench built its evaluation design around 38,666 binary market snapshots specifically because timestamped outcomes avoid the leakage problems that plague news-based or sentiment-based training data.

How do Polymarket and Kalshi resolution formats differ?

Polymarket settles on-chain with dollar-denominated payouts per share, while Kalshi settles regulated binary contracts under CFTC-compliant rules with a fixed payout structure. Normalizing between them requires mapping both into a canonical outcome enum and converting timestamps to UTC at ingestion.

Does Assymetrix provide normalized resolution data across venues?

Yes. The Assymetrix Data API normalizes resolution data across Polymarket, Kalshi, and Limitless into one schema with canonical IDs and tagged resolution sources, backed by a historical archive of roughly 1.5 terabytes and nearly one billion rows.

What’s the minimum data needed for a reproducible backtest?

You need settlement.json for the final outcome, trades.parquet for trade prints, orderbook snapshots for realistic fills, metadata.json for episode configuration, and a fee model for maker/taker costs. PredictionMarketBench structures its benchmark episodes around exactly this artifact set to keep experiments portable across research teams.