Dome API Alternative: Migrating Prediction Market Data After the Shutdown

Dome is already gone

If you're reading this because something in your codebase stopped returning data, here's the short version: Polymarket acquired Dome, both companies confirmed it on 19 February 2026, and all Dome APIs reached end of life on 28 April.

That was months ago. So this isn't a post about planning ahead for a deprecation — most people finding it now have already lost access, or have just discovered a background job that has been quietly failing since spring.

Dome's own documentation pointed developers toward Polymarket's APIs. If Polymarket data is genuinely all you need, that is the honest answer and you should take it. Their API is public, well-built and free — we wrote a guide to it, and it will cost you nothing.

The recommendation stops being useful the moment you needed more than one platform. Dome's whole point was a single integration layer across several prediction markets, and "use Polymarket's API" does not replace that. It replaces one third of it.

Work out what you actually used before you shop

The instinct after an API dies is to find the closest-looking replacement and start wiring. That usually produces a second migration six months later.

Go through your codebase first — the main application and the background jobs, which is where this kind of dependency hides — and write down every endpoint, method and response field you touched. Then sort what you find into three piles.

The first pile is normalized market data: prices, outcomes, statuses, cross-platform comparison. That is replaceable, and it is what most people used Dome for.

The second is historical data. Also replaceable, but pay attention to granularity — this is where migrations most often go wrong, because "we have history" means very different things at different providers.

The third pile is anything wallet-, position- or order-shaped. If your Dome integration tracked individual wallets, followed positions or touched order management, no market-data provider replaces that. You will need a direct platform integration for it, and you should find that out now rather than in week three.

What to actually compare

Feature lists are close to useless when everyone's says roughly the same thing. Five questions separate providers in practice.

Which platforms are live right now? Not the roadmap — today. And does coverage change between pricing tiers, because it often quietly does.

Is the data genuinely normalized? Polymarket identifies markets with condition IDs and token IDs. Kalshi uses tickers. If a provider hands you three shapes in one response, you are still maintaining three integrations, just behind someone else's endpoint.

Does it match markets across platforms, or just return them side by side? This is the expensive part to build and the easiest thing to fake. Two platforms can carry the same real-world question with different titles, different outcome labels and different settlement rules. Returning both records is not matching them.

How fresh is the data, in numbers? Refuse "real-time" as an answer. Ask for the update frequency per plan, whether streaming exists, and what the rate limits are.

And how much work is the migration? Nothing is a drop-in replacement for Dome. Authentication, endpoints, identifiers, pagination and error handling will all differ, so budget for an adapter rather than a find-and-replace.

Where we fit — and where we honestly don't

We built this API for the same problem Dome was solving: one normalized feed across several prediction markets, so you write one integration instead of three.

We currently cover Polymarket, Kalshi and Novig, with the same underlying event resolved to one ID across all three. If you used Dome for cross-platform prices, comparison, resolved outcomes or arbitrage scanning, that maps across cleanly.

Three things do not map, and it is cheaper for both of us if you know before you sign up rather than after.

We carry no wallet, position or order data. None. If that was part of your Dome integration, you need a direct platform API alongside whatever market-data provider you choose.

We do not execute trades. This is data and comparison infrastructure; execution stays with the platforms.

And our history is coarser than you may be used to. We store each market's opening odds, closing odds and resolved outcome, going back to January 2026 — not an intraday candle series. If you were pulling granular price history out of Dome, that is a real step down and the thing most likely to make us the wrong choice for you.

Don't map one provider's shape onto another

The most common migration mistake is swapping Dome-shaped objects for a new provider's objects throughout the application. That works right up until the next provider change, and then you do all of this again.

Define a small internal model covering only the fields your product actually uses — an internal event ID, the source platform, the source market ID, a title, outcomes, current price or implied probability, status, timestamps and the final result. Then write one adapter that maps an API response into it.

One caveat specific to us, and worth knowing before you design that model: we do not return volume, liquidity, bid/ask or order book depth. If your internal model has fields for those, they will come back empty. Some providers do carry them, so it is worth checking against whoever you shortlist rather than assuming.

Making the first request

Once you have a key, pull open markets across all three platforms in one call. The response nests each platform's price for the same outcome under byBookmaker, on a single event — which is the shape that makes comparison a field lookup rather than a matching exercise.

Keep the key server-side. It should never appear in browser code or a public repository.

curl "https://api.predictionmarketapi.com/v2/events\
  ?apiKey=YOUR_API_KEY\
  &bookmakerID=polymarket,kalshi,novig\
  &oddsAvailable=true\
  &limit=10"

One good response proves almost nothing

It is tempting to see valid JSON and start the cutover. Test a real spread of markets first — several categories, all three platforms, and deliberately awkward cases.

Check that matched markets really are the same question. Check outcome orientation, because getting yes and no the wrong way round is silent and expensive. Check price formats, optional fields that are sometimes absent, timestamps and time zones, the open, live, ended and finalized states, pagination, and what actually happens when you hit a rate limit.

If you are building anything that trades on a price difference, add one more test: confirm that two apparently equivalent contracts settle on compatible terms. A gap between platforms is not an opportunity when the underlying resolution rules differ, and that is a much better thing to discover in testing than in production.

Cut over gradually

Put the new adapter behind a feature flag and run it alongside whatever you have. Log every difference, every unmapped field and every unexpected status transition before you send real traffic to it.

For the first few days, watch request errors, update freshness, entity consumption against your plan limit, and data quality at the application level rather than the API level. A feed can return 200s all day and still be feeding your product something subtly wrong.

Keeping the migration isolated in one adapter means fixes stay in one file instead of spreading through the codebase — which is the same property that makes the next provider change cheap.

Three integrations, or one?

Worth asking honestly rather than assuming the answer that suits us.

If your product needs one platform, go direct. Polymarket's API is public and free, you keep full access to platform-specific features, and you pay nobody. That is a genuinely better answer than paying us.

The arithmetic changes at the second platform, and it is not really about the integration — it is about the mapping between them. Writing a second integration is tedious but finite. Keeping a cross-platform market mapping correct, as venues rename markets, split one question into several and retire contracts mid-cycle, is work that never ends.

So the question is not direct versus paid. It is whether maintaining several data pipelines is part of what makes your product good, or infrastructure you would rather not own. For an arbitrage scanner or a comparison dashboard, that plumbing is not the product. For something deeply tied to one platform's mechanics, it might be.