Why Is My Kalshi Order Not Filling? A Diagnostic Checklist

A Kalshi limit order can remain unfilled when there is no matching trade available at its price. An order can also fill only in part. Start by finding the exchange order record and its fills; a bot saying it submitted an order does not tell you how many contracts traded. Kalshi's limit-order explanation describes both non-fill and partial-fill behavior.

This walkthrough helps you assemble the evidence for one order. It does not recommend changing your price, increasing your size, or placing a replacement trade.

1. Identify the exact order

Write down the market ticker, account or subaccount, order ID, intended side, intended quantity, and submission time with timezone. Use the exchange order ID when you have it; keep any client-generated ID separately. This prevents two similar-looking orders from becoming one confusing story.

For an API integration, Get Order retrieves a single order at GET /portfolio/orders/{order_id}. Its documented response includes the ticker, status, filled and remaining quantities, prices, and timestamps. Compare those fields with the bot's record before interpreting its dashboard label.

If you only have a local message such as “request sent,” preserve the response or error and classify acceptance as unknown. Our recommended diagnostic rule is to establish what the exchange received before deciding what to do next. A timeout alone is not enough evidence for this checklist to classify an order as either accepted or rejected.

2. Separate a resting order from a completed trade

Use this worksheet to organize your observations. The rows describe investigation steps, not trading instructions.

Where you are looking matters too. For older completed or canceled orders, Kalshi partitions records between live and historical APIs. Consult its historical-data routing guide before treating a missing record as proof that an order never existed. The same guide says active resting orders remain in the live order endpoint.

3. Check the price and the queue

A buy limit sets a price ceiling; it does not promise an execution. When examining an old incident, write down which price was observed and when. A screenshot taken later cannot by itself establish what matching liquidity was available when the order arrived. Keep the order's actual limit separate from a chart price or your intended limit.

Kalshi also documents an order queue-position endpoint. It reports the quantity ahead of an order under price-time priority. That provides context for a resting order. It gives you a queue quantity; it does not give you an execution time or promise a fill.

For a support investigation, record the queue observation with its timestamp. Avoid explaining an earlier non-fill from a queue reading collected much later. This timing discipline is our recommendation for making the evidence interpretable.

4. Reconcile partial fills explicitly

Kalshi's Get Fills endpoint supports filtering by order_id and returns a pagination cursor. Follow the cursor when present, and preserve each fill's identifier, quantity, price and timestamp. For older fills, use the historical route described above. Do not silently treat the first response page as the entire history.

Illustrative example, not a customer result: you intended to buy 10 contracts. The records you collected show 4 filled and 6 still resting. Your investigation should account for the 4 executed contracts and the 6 outstanding contracts separately. A second instruction for another 10 would not describe the same outstanding quantity. This arithmetic is why the worksheet asks for filled and remaining quantities rather than a single “worked/didn't work” checkbox.

For a discrepancy in reported profit after execution is established, continue with our guide to bot P&L reconciliation. That is a different question from why an order has not filled.

5. Record the order's lifetime settings

Do not infer the intended lifetime from the word “limit.” Kalshi's V2 order specification lists good_till_canceled, immediate_or_cancel, and fill_or_kill as time-in-force choices. It also documents expiration settings for good-till-canceled orders.

Capture the actual submitted setting, any expiration timestamp, and the exchange's resulting status. This guide does not ask you to change those settings. Its purpose is to make a mismatch between the intended instruction and the recorded instruction visible.

A useful support note

Before opening a support conversation, collect this compact record through your normal private support channel:

• Market ticker and order ID.
• Account environment and subaccount, if used.
• Submission time and timezone.
• Intended side, price and quantity.
• Recorded status, filled quantity and remaining quantity, with observation time.
• Fill IDs and any response/error relevant to the discrepancy.
• One sentence describing what you expected and what you observed.

Leave API private keys, access tokens and unrelated account details out of that note. If you are still building the integration, our Kalshi API guide covers the broader setup. The next useful step for an unexplained order is a traceable record of that order—not a claim that every non-fill means the bot failed.