Statuses
The REST API returns these statuses onGET /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. |
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: whenopen_timepasses. There is noactivatedWebSocket event for this transition.active/inactive→closed: whenclose_timepasses.
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→ reopenedactive:close_timeis moved into the future. Events:close_date_updated, thenactivated.- Close time updated:
close_timechanges. 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 andresult 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
Onceclose_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 |
multivariate_market_lifecycle | MVE markets only (KXMVE*) | created, activated, deactivated, close_date_updated, determined, settled |
event_lifecycle messages when new events are created.
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`?
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?
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?
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.