Kalshi & Polymarket Prediction Market Odds Scraper

Because the markets endpoint cannot be used as a market list. On 2026-09-07, `GET /trade-api/v2/markets?limit=200&status=open` returned 25,000 rows of which 24,992 were auto-generated multivariate parlay legs — combination contracts with titles like 'yes Kaede Katayama,yes Eric Jr Olivarez,yes Aniketh Venkataraman' — leaving 8 real markets, every one of them with zero volume. Paging does not get past them; they fill the whole cursor. `GET /events?with_nested_markets=true` returns the same exchange with none of them: 11,206 events and 100,643 markets on the same day. You can check both in a browser; no key is needed. If a prediction-market dataset you already have is full of comma-separated player names, this is why.

Kalshi renamed its price and size fields and changed their type. `last_price` is now `last_price_dollars`, `volume` is `volume_fp`, `open_interest` is `open_interest_fp`, and the values are decimal strings ('0.9510') rather than integer cents. The previous names are gone, not deprecated — a request returns no such key at all. Anything written against the old names therefore reads null for every price while still producing rows of the right shape, which is why a broken feed in this category tends to look healthy rather than throw an error.

The run returns a single free row with `notice_type: source_changed` saying so, and no market rows. That is deliberate: this category's characteristic failure is a silent rename, and a dataset of correctly-shaped rows with null prices is worse than no dataset, because nothing downstream can tell the difference. The check is across the whole fetch, not per row — an individual market legitimately has no bid.

Because Kalshi's own category parameter does not work. `/events?status=open&category=Crypto` and `/events?status=open&category=Climate%20and%20Weather` return byte-identical pages — same events, same order. Passing it through would produce a filter that appears to work and silently does not. Series tickers are different: `series_ticker=` is honoured, and naming one turns a 17-second full walk into a single 0.5-second request.

The city and the station. A Kalshi temperature market's question is 'Will the maximum temperature be 86-87° on Sep 7, 2026?' — it never says Miami, and it never says CLIMIA, which is the observation station whose reading actually settles the contract. Both are stated only in the prose of the resolution rules, and both are what you need to line a bracket up against a forecast. The bracket bounds come through as numbers (`bracket_low`, `bracket_high`, `bracket_type`) rather than as text you would have to parse out of a title.

Because the market has not said anything. A contract that settles at $1 has a price that is also its probability, so where there is a last trade, or a book to take a mid from, that number is the market's own estimate. Where a market has never traded and has no resting orders, there is no estimate — and 0 would assert that the market considers the outcome impossible, which is a much stronger claim than silence. Filtering for long shots gives the same answer either way; the difference shows when you average, where a wall of false zeros would drag the mean down.

Because Kalshi's public market page is at kalshi.com/markets/<series>/<slug>, and its API never states that slug. The URL could be assembled from the parts, but an assembled link is a claim on every single row that nothing has verified, and a wrong one 404s for the buyer. `source_url` on every row is the venue's own per-market API endpoint, which was verified to answer 200, so the row is auditable either way. Polymarket does publish its slug, so its rows carry a real page link.

As many as you ask for. On 2026-09-07 there were 100,643 open Kalshi markets and about 2,100 reachable active Polymarket markets, and a full sweep of both took roughly 20 seconds. 'Maximum markets per run' caps the whole run rather than each keyword, because this Actor sweeps exchanges rather than looking things up one at a time — so the cap is your spend control. Markets are sorted by volume before the cap applies, and the run log always states how many matched, so a cap can never read as completeness.

Polymarket refuses paging past offset 2000 with 'offset too large', and caps a page at 100 rows however much you request, so about 2,100 active markets are reachable per sweep. When that ceiling is hit the run adds a free `truncated` row saying so rather than presenting a partial sweep as the whole exchange. Narrowing with a keyword reaches markets beyond it.

No. Both APIs are public, documented and keyless, and they answer a plain client in well under a second, so the proxy input is off by default and turning it on only adds latency. No Kalshi or Polymarket account is involved and nothing here is authenticated.

No. Every field is read from the venue's own response. Implied probability is arithmetic on the venue's own last trade or book, the weather city and station are quoted out of the venue's own resolution rules, and the bracket bounds are the venue's own numeric strike fields. Nothing is estimated by a model, and no field is filled in where the venue said nothing.