Kalshi API Guide: Market Data, Historical Endpoints and Order Books

Choose the correct historical object

Kalshi API keys, rate-limit tiers and cost language

Kalshi documents public market-data requests as the appropriate first-call path and requires RSA-signed API-key headers for authenticated account and trading requests. Demo and production credentials are separate. Generate and store the private key in a server-side secret store; never ship it in a browser bundle.

The current rate-limit documentation describes token budgets rather than a simple requests-per-second number: read and write buckets are separate, most operations consume a documented token cost, and higher tiers require qualification. A 429 response should trigger exponential backoff.

The official documentation does not present those token budgets as per-request dollar pricing. Treat 'Kalshi API cost' as two separate questions: the venue's current access and tier rules, which Kalshi controls, and the cost of an independent retained-history provider such as DepthFeed.

Normalize yes and no without losing the source

Kalshi represents binary outcomes as yes/no prices and sizes. A cross-venue loader may normalize those fields into a common bid/ask structure, but it should retain the native ticker, side and source values so every transformation can be reversed and audited.

Use integer or exact decimal handling for price units instead of accumulating floating-point drift. Record the observation time independently from market settlement fields; a resolved outcome must not leak into a row used by an earlier decision.

How DepthFeed records Kalshi

DepthFeed continuously polls Kalshi full-depth public books with adaptive pacing under the upstream quota and stores normalized observations with up to 100 levels per side. The realized interval varies with active-market load, so the product documents capture method rather than promising an artificial fixed tick.

The same REST schema used for Polymarket carries Kalshi ladders, timestamps and market metadata. Researchers can replay a rule in the browser, pull a historical window over the API or compare the result with live paper trading without writing a second venue-specific fill model.

A safe implementation sequence

• Read Kalshi's official documentation for current authentication, limits and endpoint contracts.
• Store series, event and market tickers with the raw yes/no book.
• Normalize prices only after preserving the native representation.
• Separate trades, candles, current books and recorded historical books in the data model.
• Use observation-time information only when evaluating an entry rule.
• Stress-test adaptive polling gaps and rate-limit responses before production.

curl -s "https://api.depthfeed.com/v3/kalshi/markets?series=KXBTC15M&start_time=2026-07-01T00:00:00Z&end_time=2026-07-02T00:00:00Z" \
  -H "Authorization: Bearer df_your_key"

curl -s "https://api.depthfeed.com/v3/kalshi/<exact_market_ticker>/snapshots?include_orderbook=true" \
  -H "Authorization: Bearer df_your_key"

Kalshi's series, event and market hierarchy

Kalshi identifiers encode a hierarchy that should remain explicit in storage. A series describes a recurring contract family, an event groups related markets, and the market ticker identifies the tradable binary proposition. Save those native keys alongside the human-readable title and any normalized cross-venue identifier.

The hierarchy matters when contracts roll, new thresholds appear or an event contains several mutually related markets. A title-only join can silently combine different expiration windows. Native tickers and timestamps make the lineage auditable and let the application return to the official market rules.

Working with Kalshi yes and no prices

Keep the native yes/no side and price unit before deriving a common bid/ask view. Binary complements are mathematically related, but available size and quoted sides still represent specific resting orders. A normalization layer should be reversible and should not manufacture liquidity on the opposite side.

Use integer price units or exact decimal arithmetic throughout ingestion, storage and fill simulation. Convert for display only at the edge. This avoids floating-point drift in complements, PnL and threshold comparisons, especially when a strategy processes many contracts.

Current books, trades, candles and recorded books

Polling cadence and freshness

When a source is polled, the interval is a property of the collector and upstream conditions, not of the exchange event itself. Active-market count, request quotas, network time and backoff all affect realized spacing. Store the receive time for every response and calculate freshness from actual observations.

Do not forward-fill a stale book and call it live. Expose last-observed time, market status and the collection method to downstream users. For backtesting, gaps should remain gaps unless the research design defines and discloses an explicit carry-forward rule.

Kalshi API quality gates

• Verify that every row carries a valid native market ticker and observation timestamp.
• Check yes/no price bounds, price-size array lengths, level ordering and duplicate prices.
• Keep exchange maintenance and closed-market periods distinct from collector failures.
• Respect official rate limits and back off without pretending the resulting cadence is fixed.
• Use as-of joins so later status, settlement and reference values never leak into earlier decisions.
• Replay sample orders against the stored ladder and report VWAP, filled size and unfilled remainder.
• Reconcile normalized output back to the native Kalshi representation during tests.