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:

Is getOrderBook strictly limited to 1 request/sec per client/API key, or is there any burst allowance?
What is the recommended approach for real-time order status tracking in such multi-order execution systems?
Should we:
- Prefer the individual order status API (details/{uniqueorderid}) instead of getOrderBook?
- If yes, what is the recommended polling strategy?
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.

admin

@TusharTyagi As per the new algo rules, client direct API product ie. SmartAPI in this case, will be used only by the end clients who run their own algo.

However, you can use postback API for your use case.