Why does this read Kalshi's events endpoint instead of its markets endpoint?

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.

What are the '_dollars' and '_fp' field names about?

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.

What happens if Kalshi renames the fields again?

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.

Why is the category filter applied after fetching rather than by the API?

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.

What do the weather fields give me that the question does not?

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.

Why is implied_probability sometimes null rather than 0?

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.

Why do Kalshi rows have no market_url?

Because Kalshi's public market page is at kalshi.com/markets/ / , 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.

How many markets can one run return?

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.

Why can't I get all of Polymarket?

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.

Do I need a proxy or an account on either venue?

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.

Is any of this data inferred or modelled?

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.

Use case

Reading Kalshi's Weather Markets by City, Station and Bracket

Kalshi's temperature contracts never name the city in the question. Here is how to get city, settlement station and bracket bounds as columns you can join to a forecast.

A Kalshi daily-temperature market asks: “Will the maximum temperature be 86-87° on Sep 7, 2026?”

That question is missing the two things you need to trade it. It does not say which city, and it does not say which weather station settles the contract. Both exist — they are written into the market’s resolution rules as prose — but neither is in the title, the subtitle, or any field called something helpful. So the natural thing to do with a temperature market, which is to line its bracket up against a forecast, needs a parsing step before you can even begin.

This is what that step looks like as columns.

The job

You want a table where each row is one temperature bracket, carrying the city, the settlement station, the numeric bounds of the bracket, and the market’s own implied probability. Then you can join it to whatever forecast you already trust and see where the market disagrees with you.

The input

Kalshi honours a series ticker server-side, which matters here: naming the series you care about turns a 17-second walk across the whole exchange into a single request of roughly half a second. The daily-high series are named by city — KXHIGHNY, KXHIGHCHI, KXHIGHMIA, KXHIGHAUS — and there are lows and rain series alongside them.

{
  "venue": "kalshi",
  "series": ["KXHIGHNY", "KXHIGHCHI", "KXHIGHMIA"],
  "maxResults": 200
}

Do not add a keyword or a category on top of a series. The filters are AND-ed, so a series plus an unrelated keyword is a correct query with an empty answer.

If you would rather sweep by category than name series, use categories: ["Climate and Weather"] with no series set. That reads the whole exchange and filters afterwards — slower, but it finds series you did not know existed. On 7 September 2026 Kalshi’s climate and weather category held 104 events across 597 markets, and its series index listed 123 temperature and rain series by city, from KXHIGHTEGLL (London) to KXLOWTMMMX (Mexico City).

What comes back

{
  "venue": "kalshi",
  "market_id": "KXHIGHMIA-26SEP07-B86.5",
  "series": "KXHIGHMIA",
  "question": "Will the maximum temperature be 86-87° on Sep 7, 2026?",
  "subtitle": "86° to 87°",
  "category": "Climate and Weather",
  "yes_price": 0.03,
  "implied_probability": 0.02,
  "volume": 6136.62,
  "open_interest": 4570.47,
  "close_time": "2026-09-08T05:00:00Z",
  "weather_city": "Miami",
  "weather_station": "CLIMIA",
  "bracket_low": 86.0,
  "bracket_high": 87.0,
  "bracket_type": "between"
}

Four fields there are the whole point of this article, and none of them is in the question text:

weather_city — Miami. Read out of the resolution rules, which say the temperature is recorded “at Miami (CLIMIA)”.
weather_station — CLIMIA. This is the one that matters for settlement. A forecast for “Miami” is not the same thing as the reading at the specific station Kalshi settles against, and the difference is exactly where a bracket is won or lost.
bracket_low / bracket_high — 86 and 87, as numbers. Kalshi states these structurally, so you are not parsing “86-87°” out of a string and hoping the dash is always the same character.
bracket_type — between, greater or less. The end brackets of a day’s ladder are open-ended: a greater market has a bracket_low and no high, and a less market the reverse.

The station codes follow the city: New York settles on CLINYC, Chicago on CLIMDW, Austin on CLIAUS. They are CLI-prefixed climate-report identifiers rather than the airport codes you might expect, which is its own small reason to take the value from the data rather than assume it.

Reading a day’s ladder

One city’s daily high is not one market — it is a ladder of brackets covering the plausible range, and they are mutually exclusive. Sorting a day’s rows by bracket_low gives you the market’s whole probability distribution for that city’s high temperature, which is a more useful object than any single price. Where your forecast sits inside that distribution is the trade.

Two practical notes. implied_probability is null rather than zero on a bracket that has never traded and has no resting orders — 0 would assert the market calls that temperature impossible, which is a stronger claim than silence, and it matters here because a ladder’s outer brackets are frequently untraded. And close_time is when trading stops, not when the temperature is measured; the Miami row above closes at 05:00 UTC on 8 September for a 7 September high.

Running it daily

Daily-high markets are created fresh each day, so this is a scheduled run rather than a one-off. Set the series you follow, run it each morning, and key on market_id — Kalshi’s tickers embed the date (KXHIGHMIA-26SEP07-B86.5), so they are stable within a day and never collide across days.

At $0.0015 per market, a run covering three cities’ full ladders is a few cents. A run that matches nothing costs nothing.

Where this does not help

If you follow one city and want today’s number, open Kalshi’s own site — it is free, and it is faster than any of this. The parsing above earns its place when you are following many cities, or keeping history, or joining market-implied probabilities to your own forecast data in bulk.

And this actor reads only what Kalshi publishes. It does not forecast weather, it does not tell you which side of a bracket to take, and it has no opinion about either.

The full how-to guide covers the rest of the input, including reading Polymarket alongside Kalshi so the same question’s price on both venues lands in one table.

The actor itself — Kalshi & Polymarket Prediction Market Odds Scraper — lists its live health, its nightly canary record and its current price.

For a different kind of forecast entirely, the Google Ads Transparency Center & Competitor Ad Scraper reads what advertisers are betting on with their budgets rather than what traders are betting on with theirs.

Last updated 2026-09-07