Intermittent ReadTimeout on place_order

rajivharlalka

Hi,

We're seeing intermittent timeouts on POST https://api.kite.trade/orders/regular from a Python OMS (Azure VM, valid session, low order rate).

1. Error

requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='api.kite.trade', port=443): Read timed out. (read timeout=5)
response_present=False, duration_s≈5.009, http_timeout_s=5
Example: SELL NIFTY26JUL24150CE, qty 65, MARKET, NRML, NFO
Happens on both OPEN (BUY) and CLOSE (SELL) during market hours

2. How we place orders

kite.place_order(
tradingsymbol="NIFTY26JUL24150CE",
exchange=kite.EXCHANGE_NFO,
transaction_type=kite.TRANSACTION_TYPE_SELL,
quantity=65,
order_type=kite.ORDER_TYPE_MARKET,
product=kite.PRODUCT_NRML,
variety=kite.VARIETY_REGULAR,
market_protection=kite.MARKET_PROTECTION_AUTO,
tag="<20-char tag from our client_order_id>",
)

3. How we handle it right now

Timeout → treat as uncertain (not rejected)
Poll kite.orders() (4×, 2s apart) for our tag
If missing → re-place (up to 2 retries), then reconcile again
Still missing → leave order pending/uncertain in our system

Setup:

The orders are places from an Azure Machine located in South Central India zone. The DNS is configured to be cloudflare DNS. The strategies and the execution happens inside docker containers but with no firewall restrictions.

Questions:
1. Is this a known issue and is there a good way to fix this completely as reconciling and re-placing an order sometimes gives us 15 sec delayed orders
2. Can the order be accepted server-side even when we get ReadTimeout?
3. Any recommended idempotency approach beyond tag + orders() polling?

Nivas

The timeout could be caused by the client network, the network path between the client and our servers, or could be a connection pool issue.

A ReadTimeout indicates that the client did not receive a response within the configured timeout period. We recommend treating such cases as uncertain and reconciling the order status by fetching the orderbook before attempting to place the order again. This helps avoid duplicate order placement.

You can handle the exception as shown below:

try:
     Your code logic here
except ReadTimeout:
	pass

If the order is not found in the orderbook after reconciliation, you may proceed with your retry logic.