Market Lifecycle - API Documentation

Markets on Kalshi follow a lifecycle from creation through trading to determination and settlement. This page describes the states a market passes through and what to expect at each stage.

Statuses

The REST API returns these statuses on GET /markets and GET /markets/{ticker}:

Status	Meaning
`initialized`	Created but not yet open for trading. Transitions to `active` when `open_time` passes.
`active`	Open for trading.
`inactive`	Temporarily deactivated by the exchange. Trading is paused but the market has not closed.
`closed`	Past `close_time`. No new orders accepted. Awaiting determination.
`determined`	Result is known. Settlement timer is running.
`disputed`	Result has been challenged. May be re-determined.
`amended`	Re-determined after a dispute. Settlement timer restarts.
`finalized`	Settlement complete. Positions have been paid out. Terminal state.

When filtering with GET /markets?status=, the values map as follows:

Filter value	Matches
`unopened`	`initialized` (before `open_time`)
`open`	`active`
`paused`	`inactive`
`closed`	Any market past `close_time` that is not yet `finalized`
`settled`	`finalized`

Transitions

Some transitions are implicit (time-based), others are explicit (event-driven). Implicit (no WebSocket event):

initialized → active: when open_time passes. There is no activated WebSocket event for this transition.
active / inactive → closed: when close_time passes.

Explicit (WebSocket event emitted):

active → inactive: exchange deactivates the market. Event: deactivated.
inactive → active: exchange reactivates a paused market. Event: activated. All resting orders are cancelled on this reactivation.
closed → reopened active: close_time is moved into the future. Events: close_date_updated, then activated.
Close time updated: close_time changes. Event: close_date_updated. This can happen when a market is closed ahead of its scheduled close time, including before determination.
closed → determined: result is set. Event: determined.
determined / amended → finalized: positions paid out. Event: settled.

Time fields

Markets have several time fields:

Field	Meaning
`open_time`	When the market opens for trading.
`close_time`	When trading stops. May be moved earlier if `can_close_early` is true.
`expected_expiration_time`	When the outcome is expected to be known.
`latest_expiration_time`	Latest possible expiration time.
`expiration_time`	Deprecated legacy field. Prefer `latest_expiration_time` for the legacy expiry semantics; use `expected_expiration_time` if you want the forecasted time.

Determination and settlement

After a market closes and the outcome is known, the market is determined and result is set to yes, no, or scalar. A settlement timer then runs for settlement_timer_seconds, which is visible in the REST response. During this window the market remains at determined and the result may be disputed. Once settlement completes, positions are paid out. In REST, settled markets end up at finalized rather than a separate settled status, and settlement_ts is populated.

Orders after close

Once close_time passes, all order operations, including cancellations, are rejected with MARKET_INACTIVE. Resting orders are cancelled shortly after close, and cancellation updates are published on the usual user channels.

WebSocket

Market lifecycle events are delivered on two channels:

Channel	Markets covered	Event types
`market_lifecycle_v2`	All markets except MVE (`KXMVE*`)	`created`, `activated`, `deactivated`, `close_date_updated`, `determined`, `settled`, `metadata_updated`
`multivariate_market_lifecycle`	MVE markets only (`KXMVE*`)	`created`, `activated`, `deactivated`, `close_date_updated`, `determined`, `settled`

Both channels also emit event_lifecycle messages when new events are created. The market_lifecycle_v2 channel additionally emits event_fee_update messages when an event-level fee override is set or cleared. The WebSocket settled event corresponds to settlement being processed; in REST, settled markets end up at finalized.

FAQ

Why can `expected_expiration_time` be before `close_time`?

expected_expiration_time is the time the event is likely to resolve (for a sports game, typically a few hours after the scheduled start). close_time is when the market automatically closes for trading, and may be set well into the future to allow for rescheduling. That means expected_expiration_time can be earlier than close_time.

Why might `GET /markets/{ticker}` return `404` right after a `created` event?

The market may not be queryable immediately after a created event. Retry with backoff.

Do event responses include a top-level `status` field?

GET /events supports a status filter with values unopened, open, closed, and settled. The filter matches on child market statuses, not an event-level status; an event appears in results if any of its child markets has a matching status. For example, an event with four open markets and one settled market matches both status=open and status=settled. Use with_nested_markets=true if you need individual market statuses.

​Statuses

​Transitions

​Time fields

​Determination and settlement

​Orders after close

​WebSocket

​FAQ