> Full docs in one file: https://kacdata.com/llms-full.txt

# Overview

Source: https://kacdata.com/docs/historical-data-details/overview

> How KacData collects Kalshi market data and what is available through the API.

Historical data details describes how KacData collects Kalshi data and what's available via the KacData [HTTP API](https://kacdata.com/docs/api-reference). Data is provided as Parquet files, one file per market per UTC day.

You'll find here details about:

- historical data availability — since when historical data has been collected and is available
- captured real-time market data channels — historical market data is sourced from the Kalshi WebSocket API and can be downloaded by data type. For example, to get the historical trades of a market, provide the data type `trades` and the requested `market_ticker` via the [HTTP API](https://kacdata.com/docs/api-reference).

## Market data collection overview

- All market data collection is performed in AWS `us-east-2`, colocated with Kalshi.
- The most granular, non-aggregated data feed is always collected.
- Kalshi data is collected from the Kalshi Trade API WebSocket v2. One connection subscribes to every market, so new markets are recorded as soon as Kalshi publishes them.
- Two WebSocket connections record the same feed to help prevent data loss. Messages received on both are stored once.
- Each received message is timestamped at arrival time and stored in UTC as `timestamp[us]` in `local_timestamp`. `timestamp` is the time Kalshi supplies in the message, where there is one.
- Timestamps come from a clock synchronized with chrony to [AWS PHC](https://aws.amazon.com/blogs/compute/its-about-time-microsecond-accurate-clocks-on-amazon-ec2-instances/), which AWS documents with a clock error bound typically under 40 µs. The bound is the most the clock can be off; the actual offset is usually far smaller.
- Messages are stored as received: one row per message, field names converted to snake_case, prices and sizes stored as `decimal(18,4)`.
- Market data collection services are constantly monitored both manually and via automated tools, including monitoring and alert notifications, and have built-in self-healing capabilities.
- There are multiple built-in checks that detect whether a connection to an exchange is healthy during data collection:
  - **Connection silence detection** — if no messages or control frames are received for more than 30 seconds, the connection is automatically restarted.
  - **Market data silence detection** — even if PONG messages are still received, the connection is automatically restarted if market data for the current subscriptions remains absent.
  - **Message format validation** — JSON format and data items are checked; errors are recorded and processing continues so that an invalid message does not interrupt collection.

## Collected order book data details

Kalshi sends a full order book snapshot only on subscription, reconnection, new markets and expiry; every other change is a signed delta. A day's file on its own could therefore not be replayed. To make each file self-contained, KacData adds two synthesized rows to every L2 file:

- The first row is the start-of-day (SOD) order book: the previous day's end-of-day book. Its `timestamp` and `local_timestamp` are both 00:00:00 UTC of that day.
- The last row is the end-of-day (EOD) order book: the day's last snapshot with every later delta applied in file order. Its `timestamp` and `local_timestamp` are both 00:00:00 UTC of the next day.

Replay from the first row of the file. See the [L2 schema](https://kacdata.com/docs/schemas/l2) for the replay rules.

## Per-exchange historical data details

- [Kalshi](https://kacdata.com/docs/historical-data-details/kalshi)