Rate Limit Constraint on getOrderBook API Causing Order Status Sync Issues in Multi-Order Strategy Execution

[TusharTyagi]

Hi Team,

I am currently integrating Angel One SmartAPI into a production-grade algorithmic trading platform and facing a limitation around order status synchronization due to API rate limits.

System Design Context:

• Each client can have multiple strategies
• Each strategy executes multiple orders concurrently
• Orders are placed using placeOrder API

Example structure:

Client
 ├─ Strategy 1 → Order A, Order B
 ├─ Strategy 2 → Order C, Order D
 ├─ Strategy 3 → Order E, Order F

Current Behavior:

• With placeOrder API (~9–10 req/sec), I am able to successfully place multiple orders concurrently
• However, for order status tracking, I rely on getOrderBook

Problem:

• getOrderBook API is limited to ~1 request per second

• Since multiple orders are placed in parallel, I need to frequently fetch updated statuses

• But due to this strict rate limit, I am unable to:

  • Fetch timely updates for all active orders
  • Maintain real-time order state in my application
  • Ensure correct strategy execution flow (especially for dependent orders)

This creates a mismatch:

I can place multiple orders quickly, but cannot track their status at the same pace.

---

Impact:

• Delay in order status updates (OPEN → COMPLETE / REJECTED)
• Strategy execution inconsistencies
• Increased reliance on stale data
• Potential trading risks in high-frequency scenarios

---

Clarification Required:

1. Is getOrderBook strictly limited to 1 request/sec per client/API key, or is there any burst allowance?

2. What is the recommended approach for real-time order status tracking in such multi-order execution systems?

3. Should we:

   • Prefer the individual order status API (details/{uniqueorderid}) instead of getOrderBook?
   • If yes, what is the recommended polling strategy?

4. Are there any event-based / WebSocket-based alternatives planned for order status updates?

---

Expected Guidance:

Given the use case of concurrent multi-order execution, I would appreciate guidance on:

• Best practices for scalable order tracking
• Recommended API usage pattern for high-frequency systems
• Any internal throttling or batching strategies suggested by Angel One

---

Summary:

The current rate limit asymmetry between placeOrder (~10 req/sec) and getOrderBook (~1 req/sec) makes it difficult to maintain real-time order state in systems executing multiple orders concurrently.

---