How to Download Kalshi Historical Data

This is the practical answer to "how to download Kalshi historical data": where a settled market's trades and order books actually live, what the venue itself publishes, and the exact clicks and commands that turn a Kalshi series into files on your disk. The archive behind it is the CryptoStruct Kalshi data capture — every open contract recorded tick by tick, co-located, in the same schema as our crypto venues — and the workflow below is the one our own research team uses. If you only need a Kalshi data download for a single contract you can stop after step 2; the free sample is a complete, real day.

Does Kalshi provide historical data?

Partly. The official Kalshi API (check the current docs — the surface changes) serves market lists, settlement outcomes and some historical trade and price data per market, which is enough for a Kalshi price history chart or a settlement table. What it does not do, as far as the public docs go, is let you replay the full tick-by-tick order-book path of a market that has already settled: the depth that was resting at each price level, how it moved into the final minute, and which side got hit. That state only exists if someone recorded it live while the market was open.

Short-interval series make the gap brutal. A 15-minute Bitcoin market exists for fifteen minutes and is replaced by the next one; start collecting today and in three months you own three months. This is why "where can I find historical data for event contracts" is a harder question than it sounds — the answer is an archive that was running at the time, and that is what the rest of this guide downloads from.

What a Kalshi historical data download contains

Every Kalshi contract that was open on a UTC day is one file: {instrument_id}_{date}.txt.zst, zstd-compressed JSON lines. Line one is the instrument masterdata (ticker such as KXBTC15M-26SEP01…, tick size, state), every other line is one event — an order-book snapshot, an incremental Level-2 update or a trade — with both the venue timestamp and our capture timestamp in integer nanoseconds UTC. The full walkthrough with real sample lines is in the file-format guide.

Because a single contract file is tiny — about 94 KB compressed on average in our 2026-09 measurement — the shop sells Kalshi by the **series-day bundle**: every contract file of one series for one UTC day, from €1. A series is a family of markets sharing a ticker prefix, for example all KXBTC15M-… fifteen-minute Bitcoin windows or the KXBTCD-… daily strike ladder; as of 2026-09 the registry lists 1,625 Kalshi series across sports, politics, economics, climate, culture, science and crypto. Single contract-days remain available at €1 each in the instrument shop if you only want one market.

Step 1 — find the series

Kalshi tickers are cryptic, so start from a hub instead of a search box. The topic hubs group series the way people search for them — NBA, CPI, Fed, Bitcoin up-or-down, hurricanes — and the most-traded leaderboard ranks every series by trades and USD turnover over the last 30 days from our own capture, which is the fastest way to see where the liquidity is. Every series page under /prediction-markets shows its Kalshi ticker prefix, first and last recorded day, per-day statistics and the biggest contracts of recent days, so you can judge a series before paying for it. Agents do the same through the MCP server: search_bundles resolves a phrase like "kalshi btc 15 minute" to the series key.

Step 2 — download the free sample contract

Each series page offers one free contract file: the busiest contract of a settled day about a week back, byte-identical to what the shop delivers. Download it, then run the free reader from the AI toolkit to see what is inside before you write a line of code:

# counts per message type, first/last timestamp, book snapshots
python3 cryptostruct_reader.py info kalshi-KXBTC15M-…-2026-09-01.txt.zst

# deep audit: chain gaps, crossed states, coverage in seconds
python3 cryptostruct_reader.py stats kalshi-KXBTC15M-…-2026-09-01.txt.zst --deep

The sample is also the right file to test a parser against, and it opens in the browser replay viewer linked from the series page if you prefer to watch the book move before touching Python. The downloads page carries additional free days across crypto venues in the same format.

Step 3 — buy the days you need

Open the series in the day-bundle shop, pick days in the calendar — each series-day is €1 by default, some larger series price higher and show it on the tile — and check out. Payment is by card through Stripe with an invoice on every order, or with credits: a Premium membership includes 50 credits a month, and credit packs add a bonus on top for larger histories. Purchased days never expire; they stay in your account with their download links, and any day added later to the same series can be bought on its own.

1. Pick the series (or several) and the date range in the calendar; the cart shows the total before you pay.
2. Check out with card or credits — an invoice is issued automatically.
3. The order page lists every day with a download button, a ZIP for the whole day and the readiness of any cold-storage files.
4. Days older than about a month may sit in deep-archive storage; one click restores them, and they become downloadable within roughly twelve hours.

Step 4 — bulk download: one archive per day, one tar per range

A Kalshi series-day can hold hundreds or thousands of contract files, so never fetch them one request at a time. Two delivery shapes cover every history size. The order download URL with kind=series_day&zip=1 streams every contract file of that day as one archive; add complete=1 for scripts so a partially-available day fails loudly instead of returning a short archive. For many days of the same series, the range endpoint returns every owned day inside a window as a single uncompressed tar with an exact content length and a strong ETag — so curl -C - resumes where it stopped, and a short transfer is always a visible error. It covers up to 100 days per stream and answers 409 before the first byte when a day is still cold, so poll status=1 first.

# one day, every contract file, strict
curl -fL -o 2026-09-01.zip \
  "https://cryptostruct.com/api/download/order/{order}/{bundle}/2026-09-01?kind=series_day&zip=1&complete=1&t=$TOKEN"

# readiness of a whole range (NDJSON, one line per day) — wait for cold == 0
curl -s "https://cryptostruct.com/api/download/order/{order}/{bundle}/range?kind=series_day&from=2026-08-01&to=2026-09-01&status=1&t=$TOKEN"

# then the range itself: one resumable tar, extract into {date}/ folders
curl -fL -C - -o kalshi-btc-15m_2026-08.tar \
  "https://cryptostruct.com/api/download/order/{order}/{bundle}/range?kind=series_day&from=2026-08-01&to=2026-09-01&t=$TOKEN"
tar -xf kalshi-btc-15m_2026-08.tar

The {order} and {bundle} ids and the download token come from the order page; the same URLs accept manifest=1 to list what a day or range will contain and restore=1 to bring a whole range back from cold storage in one call. The complete contract, including the 413 split hint for ranges over 100 days, is documented on the downloads page.

Step 5 — CSV, Parquet or your own parser

If you do not want to touch JSON lines at all, every sample and purchased file also serves flat exports: append ?format=trades.csv.gz or ?format=trades.parquet to its download link and you get the docs-convention columns — exchange, symbol, exchange timestamp, adapter timestamp, trade id, side, price, quantity — with integer microsecond UTC timestamps (the native files keep nanoseconds). For the order book there is no flat export on Kalshi because there is no BBO stream to flatten; instead the reader replays the L2 book locally and samples it on a fixed grid, which is also the shape most models want:

# trades of every contract file → one Parquet per file
for f in 2026-09-01/*.txt.zst; do
  out="parquet/trades_$(basename "$f" .txt.zst).parquet"
  [ -f "$out" ] || python3 cryptostruct_reader.py trades "$f" --out "$out"
done

# order book every second, 20 levels per side, from the L2 replay
python3 cryptostruct_reader.py book 2026-09-01/kalshi-KXBTC15M-…-2026-09-01.txt.zst \
  --every 1s --depth 20 --out book_1s.parquet

Days are independent, so parallelise the loop with xargs -P. Writing your own parser is a few dozen lines — iterate, json.loads, switch on the message type — but read the three pitfalls in the format guide first: multi-frame zstd, decimal strings, and nanosecond integers that overflow JavaScript numbers.

search_bundles      {"q": "kalshi btc 15 minute"}          → series_key kalshi-btc-15m
get_bundle_sample   {"series_key": "kalshi-btc-15m"}       → free contract file + CSV/Parquet links
create_checkout     {"items": [{"series_key": "kalshi-btc-15m", "dates": ["2026-09-01", "2026-09-02"]}]}
get_order_files     {"order_id": "…"}                      → per-day ZIP + range URLs

Using the data: four things that bite backtests

• Anchor on the contract window, not the file. A KXBTC15M market's book is quoted for roughly fifteen minutes; the file may be longer. Cut features at the window's open and stop at its close.
• Consecutive day files overlap: recording starts about eight minutes before midnight UTC and ends about one minute after. Trim to the nominal day or deduplicate on event id before stitching days.
• The outcome implied by the last print (close ≥ 0.97 for Yes, ≤ 0.03 for No — the convention our statistics tables use) is not the official resolution. Take labels from Kalshi's settlement metadata.
• Kalshi runs scheduled maintenance on Thursdays, 03:00–05:00 ET, which shortens its fifteen-minute and hourly crypto series on those days; expect fewer windows and check coverage before assuming a gap is a recording fault.

How many settled windows a series yields per day, and why walk-forward splits are non-negotiable, is worked out in how much data an up/down bot needs; how the Kalshi book compares to Polymarket's on the same product is measured in Kalshi vs Polymarket.

What you can download today

Limitations

Our Kalshi capture is recent — the venue page shows the live first recorded day and the current instrument count; there is no data before it, and a small number of days have venue-side outages that show up as short files or missing windows. The series registry covers the families with meaningful activity, not every ticker Kalshi has ever listed, and new families join at the monthly review. Tick sizes and contract rules are market-specific and taken from the venue at recording time; statements about the official API describe its public documentation as we read it and may lag changes. Nothing here is investment advice — it is a download guide.