I am researching the technical and operational requirements for a risk-controlled retail algorithmic trading system using Kite Connect.
I would appreciate clarification on the following API behaviour. I am seeking documented technical information and am not assuming that API support by itself establishes regulatory permission.
A. LIMIT + IOC and order types
1. Does Kite Connect support placing LIMIT + IOC orders for NFO NIFTY index options through an individual retail Kite Connect API application?
2. Are there any Kite Connect, account-level, exchange, or retail-algo restrictions or prerequisites that would prevent or limit this order combination?
3. How does Market Protection (MPP) apply to API orders? Does it apply only to MARKET orders, or can it affect LIMIT orders as well? Please clarify the distinction between submitting MARKET + MPP and LIMIT + IOC.
B. Partial fills and order reconciliation
4. For a LIMIT + IOC order that is partially filled, does the API report the executed quantity and automatically cancelled unfilled remainder separately?
5. Which API endpoints and response fields should be treated as authoritative for determining the final order status, filled quantity, cancelled quantity, pending quantity and average execution price?
6. Can order-book, order-history, trade-book and positions data temporarily disagree or arrive at different times? What is the recommended reconciliation procedure in such cases?
7. If an IOC order is not matched at all, what final status and response fields should the client expect?
8. If an order is partially filled and the remainder is cancelled, is the order's final status reliably distinguishable from a fully filled or fully cancelled order?
C. Ambiguous submissions, retries and idempotency
9. If an order-placement request times out or the client loses its connection before receiving the order ID, how should the client determine whether Zerodha accepted the order?
10. Does Kite Connect provide a documented idempotency key or any other mechanism that guarantees duplicate prevention when an order-placement request is retried?
11. Can the optional order tag be used to locate an order whose placement response was lost? Is the tag searchable through order APIs, and does it provide any duplicate-order prevention guarantee?
12. What is the recommended procedure before retrying an order when the original submission has an unknown status?
D. Primary/backup hosts and static IPs
13. If an application has two registered static IP addresses (primary and secondary), does Zerodha enforce any broker-side mechanism that prevents both hosts from placing orders simultaneously?
14. Is there any supported ownership, fencing, or failover mechanism that prevents a previously active host from continuing to submit orders after a backup host takes over?
E. API limits and operational details
15. Please clarify the applicable order-placement, modification, cancellation and order-query rate limits, along with the availability and retention period of order and trade records needed for reliable reconciliation.
Where possible, please provide links to the relevant official documentation or applicable technical rules.
