Photo: Jakub Żerdzicki / Unsplash, used under the Unsplash License.
good_till_canceled, immediate_or_cancel, and fill_or_kill. Those are event-market controls; do not copy leverage or liquidation behavior from Kalshi's separate perpetual-futures help pages.The word order type is used loosely. In the consumer event-contract interface, Kalshi documents Quick Orders and Limit Orders. In the current event-market API V2, every request includes a price and combines it with a time_in_force instruction. That instruction determines whether the unmatched quantity rests, cancels, or requires an all-or-none immediate fill.
This distinction matters because Kalshi also has a help page named “Order Types” for perpetual futures. That page discusses leverage, short positions and liquidation. Those mechanics do not describe a basic $1-or-$0 event-contract purchase. This guide is limited to event contracts and the event-order endpoint.
Kalshi's event-contract help center calls a Quick Order a market order. You select YES or NO and a quantity or dollar amount; the interface seeks the best available prices. If the requested quantity is larger than the quantity at the best price, the fill can span several levels.
Kalshi's own example uses 500 contracts at 10 cents and another 500 at 12 cents. A Quick Order for 1,000 would average 11 cents if that liquidity remained available. The key output is therefore not only the first displayed ask, but the estimated average price, worst level and total quantity.
Before a Quick Order, walk the visible book or use the slippage calculator with copied levels. The calculator is an estimate and does not reserve liquidity.
A buy limit says the maximum price you will pay; a limit sale says the minimum price you will accept. If compatible liquidity is already available at that price or better, part or all of the order can execute immediately. Otherwise the unmatched portion can become a resting order.
A limit order does not guarantee that the contract will trade at your price before the market closes. It also does not guarantee maker treatment. A marketable limit that crosses an existing order is a taker execution; only quantity that first rests and is later matched is maker-side quantity.
API V2 uses good_till_canceled. Without expiration_time, the documentation describes it as a true good-till-canceled order. With an optional Unix timestamp in seconds, the same time-in-force value creates an order that should rest only until that time.
The docs explicitly warn that GTT is not a valid REST API value. A developer should send good_till_canceled plus expiration_time, then verify the returned order state. Kalshi's FIX interface uses different TimeInForce codes, including GTC and GTD, so do not copy FIX enum values into REST JSON.
immediate_or_cancel tries to match immediately at the limit price or better. It can fill partially. Any portion that cannot execute immediately is canceled rather than left in the book.
Example: an IOC bid requests 100 contracts with a 52-cent limit. If 30 compatible contracts are available at 51 cents and 20 at 52 cents, 50 can fill and the other 50 are canceled. The actual response should be checked through fill_count, remaining_count and average_fill_price; the requested count is not proof of the filled count.
IOC is useful when a stale remainder would be harmful, but it does not solve partial-position risk. The caller still needs a rule for what to do if only part of the quantity executes.
fill_or_kill is the event-market API V2 choice for an immediate all-or-none attempt. The entire requested quantity must be executable within the price boundary or the attempt is canceled without a partial position. Kalshi's FIX docs likewise list FOK as a supported TimeInForce value.
FOK protects the requested position size from partial execution; it does not guarantee that the order will trade. It can return no fill when the total visible or available quantity is insufficient. Always verify the response instead of inferring success from a successful HTTP connection alone.
| Control | Where documented | Can fill partially? | Can remainder rest? | Primary tradeoff |
|---|---|---|---|---|
| Quick Order | Event-contract interface | Execution can span levels; verify completed quantity | No intended resting instruction | Speed versus average-price slippage |
| Limit Order | Event-contract interface | Yes | Yes | Price control versus no-fill risk |
good_till_canceled | Event API V2 | Yes | Yes, until cancel or optional expiration | Persistent liquidity versus stale-order risk |
immediate_or_cancel | Event API V2 | Yes | No | Immediate partial allowed; remainder canceled |
fill_or_kill | Event API V2 | No | No | Full immediate size or no execution |
The current endpoint is POST /trade-api/v2/portfolio/events/orders. For event markets, V2 quotes the YES leg: bid means buy YES and ask means sell YES. Selling YES is economically equivalent to buying NO at the complementary price. The request uses fixed-point dollar strings.
{
"ticker": "EXAMPLE-TICKER",
"client_order_id": "unique-idempotency-key",
"side": "bid",
"count": "25.00",
"price": "0.5200",
"time_in_force": "immediate_or_cancel",
"self_trade_prevention_type": "taker_at_cross",
"post_only": false,
"cancel_order_on_pause": true,
"reduce_only": false,
"subaccount": 0,
"exchange_index": 0
}This is a field-shape example, not a live trading instruction. Authentication, signatures, unique client IDs, balances, market state, position limits and error handling are outside the snippet. The API docs say the legacy order path is scheduled for deprecation, so new integrations should follow the current V2 page rather than copying an old request.
post_only: intended to prevent the order from taking resting liquidity. The API changelog documents a post only cross invalid-order response for a batch order that would cross, so clients must handle rejection rather than assume the exchange silently moves the price.cancel_order_on_pause: when true, Kalshi's maintenance guide says an open order is automatically canceled when a trading or exchange pause begins. When false, it can remain resting and resume after activity reopens.reduce_only: the create-order docs say the placed count is capped by the member's current position. Treat it as a position-reduction safeguard, not a substitute for reconciling fills and positions.API V2 has separate endpoints to cancel an event order, decrease its remaining count and amend price or maximum fillable count. The amend docs say the new count must equal already filled quantity plus the desired remaining quantity. That makes fill reconciliation a prerequisite, not an afterthought.
An order can match while a client is deciding to cancel or amend it. After any mutating request, use the returned matching-engine timestamp and counts, then query order and fill state as needed. Do not assume that a button click or network request erased quantity that had already executed.
Kalshi's event-contract help center calls a Quick Order a market order. It seeks immediate execution at the best available prices and can span multiple price levels when the requested quantity exceeds the best level.
No. A buy limit controls the maximum price and a sale limit controls the minimum price, but the order can remain unfilled if compatible liquidity never reaches that boundary.
Yes. Immediate-or-cancel can execute the quantity available at the limit or better and cancel the unfilled remainder. The API response exposes fill_count and remaining_count for review.
Fill-or-kill is an event-market API V2 time-in-force option for an all-or-none immediate attempt: the entire requested quantity must be executable within the limit or the attempt is canceled without a partial fill.
Yes. API V2 uses good_till_canceled for a true GTC order when no expiration is supplied, and the same value with expiration_time for a resting order that should expire at a specified Unix timestamp.
No. A limit that matches resting liquidity immediately is taking liquidity, while an order that first rests can later be a maker fill. Product-specific maker fees can apply, so the current fee schedule and order ticket remain the sources of truth.