Kalshi Historical Data: Find Older Markets, Trades and Fills

If an older Kalshi market or fill disappears from a live API response, check the historical endpoints before concluding the record is missing. Kalshi separates recent and archived data, with different cutoffs for different record types. This guide helps you assemble a bounded research export and record what it covers. Kalshi’s archive guide explains the partition.

Our public API check on October 7, 2026 used three GET requests: the cutoff, one archived market, and that market’s candles. Each returned HTTP 200; the candle response contained one row. That is a small connectivity and response-shape check. We did not exhaust pagination or access anyone’s account history. The private fills and orders workflow below is documentation-based and unexecuted.

Choose the records before choosing an endpoint

These routes answer different questions. The public trades feed describes transactions across markets. Your historical fills are authenticated account records and include identifiers for the fill and its order. Keep those datasets separate. For an old market lookup, the historical markets reference offers ticker, event, or series filtering; its filters are mutually exclusive.

This collection plan excludes position balances and settlement records. Their archival handoff has additional rules, so it does not establish a complete account statement. Consult the separate position and settlement guidance in Historical Data when those records are your actual objective.

Read the cutoffs each time

Start with GET /historical/cutoff and save its response alongside your export. The cutoff reference identifies market_settled_ts, trades_created_ts, and orders_updated_ts; do not substitute one field for all three. These timestamps move, so a fixed “last 30 days” assumption is unsafe.

Market routing depends on settlement time; trade and fill routing depends on fill time; completed or canceled order routing depends on cancellation or execution time. Resting orders remain on the live orders endpoint. A range spanning an archive boundary needs the corresponding live and historical reads. Kalshi documents these distinctions.

A bounded collection checklist

1. Name the environment and question. For example: “production market data for one series over this UTC interval.” Kalshi’s production and demo environments use separate hosts and credentials. The current recommended production REST base is https://external-api.kalshi.com/trade-api/v2.
2. Capture a small market inventory. Choose one supported historical-market filter. Save market and event tickers, settlement timestamps and collection time. Keep the raw response before producing a spreadsheet; otherwise later parsing decisions become hard to inspect.
3. Collect the needed record type. For your own fills, select the intended subaccount explicitly and check the key’s scope. A subaccount-restricted key cannot retrieve other subaccounts. The historical fills reference supplies ticker, time and subaccount parameters. For order records, check the separate historical orders reference; do not assume a fills query and an orders query have identical meaning.
4. Finish every selected page sequence. Carry each response’s cursor into the next request with the same filters, until no next cursor remains. Record a failed request as an incomplete export. Kalshi’s pagination guide also warns that data may change between requests; finishing the pages does not create a frozen exchange snapshot.
5. Reconcile before analyzing. Retain original record IDs, endpoint, environment, account scope where applicable, and timestamps. Check duplicate IDs within each dataset and inspect disagreements instead of silently adding repeated rows. Compare returned date coverage with the requested range. An unexplained gap belongs in the manifest.

Put a coverage manifest next to the data

Use this as a worksheet for each collection, with actual values from the run. It is our proposed record format, not a Kalshi response schema.

Keep authentication headers and private keys out of the manifest. Preserve account records privately. This workflow is for your own research and authorized account review; it makes no claim about rights to redistribute exchange data.

An example of apparently missing history

Synthetic example: You request a 60-day interval of your fills from the live endpoint and receive only recent rows. After reading the current cutoff, you request the older portion from the historical fills endpoint, finish both page sequences, and reconcile identifiers. The earlier rows might resolve the gap. If they do not, mark the export incomplete and check environment, account scope, filters and errors. No record counts or dates in this example represent a customer account.

Candles answer a narrower question

For archived markets, the historical candlestick endpoint takes a ticker, start/end timestamps and an interval of 1, 60 or 1,440 minutes. Its response summarizes bid, ask and trade-price information by interval. That aggregation does not tell you where a hypothetical order sat in a queue or whether it would have filled.

The orderbook endpoint describes the current book. Calling it now does not recover a past orderbook. Treat trade prints, candles and account fills as different evidence, and state when the historical inputs your research needs were never collected.

Start by completing the manifest for one market and one question. If you need authentication or general discovery help, use our Kalshi API guide. If you have assembled the data and want to evaluate a strategy, continue with how to backtest a Kalshi strategy. An export is an input to that work; it is not evidence of profitability.