Indian broker APIs: WebSocket stability at open, expiry

Retail algo traders on Reddit and developer groups keep circling back to one question: which Indian broker API stays stable when it matters. The recurring pain points are dropped WebSocket connections, delayed order updates, and intermittent errors during volatile periods. Most threads treat WebSocket support as mandatory for live feeds, but they also stress that disconnects still happen. The practical takeaway is less about marketing claims and more about building defensive systems. Discussions also separate “average latency” from sudden spikes that show up at market open, expiry, and sharp moves. Many users say the 99th percentile is where strategies get hurt, not the median.

Why WebSocket stability is treated as a first-class metric

Developers repeatedly describe WebSockets as the default for continuous tick streams. They contrast this with REST, where each request is a fresh call and can feel slower for fast-changing data. The stability problem is not theoretical in these threads, because drops tend to cluster in volatile windows. Users mention that even “reliable” feeds can disconnect and then reconnect after missing ticks. That gap can change entries, exits, and hedge timing, especially for multi-leg positions. Several posters warn that “WebSocket available” is only a checkbox unless you test it live. They also highlight live order updates as a separate stream that must stay healthy. The implied standard is: stable streaming plus predictable recovery when it fails.

The times when latency spikes get noticed most

The most repeated timing callouts are 9:15 am market open, expiry days, and sudden sharp moves. Traders say these are the moments when strategies are most active, so the impact compounds. Some posts frame this as jitter rather than a steady slowdown. Others describe delayed order updates and intermittent errors, which creates uncertainty about state. Several users say comparing average response time misses the point. They focus on the tail, calling the 99th percentile the “real risk point.” Social threads also note that these spikes can worsen slippage and reduce queue priority. The common suggestion is to measure your own error rates during the exact windows you trade.

What retail algo builders check first in a broker API

Across threads, the checklist starts with order execution via REST endpoints and market data via WebSocket streaming. Most users want order placement, modification, and cancellation covered cleanly. They also expect historical OHLC data, plus portfolio and account endpoints. Documentation quality and SDK coverage show up as practical differentiators during outages. Community size matters because debugging often becomes community-driven when something breaks. A few posts call out sandbox testing as a safety feature for beginners. Traders also look for clear rate limits so systems can throttle predictably. The overall framing is operational: reliability, limits, and failure modes.

Consolidated broker notes traders keep reposting

The table below reflects what users reported and debated in the same threads, including uncertainty where pricing was disputed. Reliability notes are user-described experience, not a benchmark. Some brokers are discussed for stability and documentation, while others are discussed for rate limits or product positioning. Response-time lists are circulated as context and not as a guarantee of fills. Several posts explicitly warn to validate claims with live trading-day tests. Even where a broker is “widely used,” users still recommend building reconnection logic. Costs also vary by data packs or plan choices in user comments. Treat the table as a starting point, not a selection checklist.

WebSocket and REST: how developers split responsibilities

A common design pattern in posts is: REST for trading actions, WebSocket for streaming market data. Users say REST calls are simpler to reason about for order placement acknowledgements. For ticks, they prefer WebSockets because they avoid repeated polling overhead. Several threads still mention WebSocket-based order updates as valuable for state reconciliation. People describe delayed order updates as a different failure from delayed ticks, but equally damaging. Some traders recommend queuing or pausing order logic when the streaming link is down. Others focus on building an internal “last known state” to handle temporary gaps. The theme is separation of concerns with clear fallbacks.

Token expiry and session management are not optional

Multiple posts highlight daily token expiry patterns, making automated refresh a production requirement. Some users say tokens typically expire at midnight, while others mention invalidation windows between 1:00 a.m. and 6:00 a.m. IST the following day. Zerodha Kite Connect is explicitly described as having daily token expiry, needing a fresh token each trading day. Upstox tokens are discussed as longer-lived compared with Kite. OAuth-style redirect flows are mentioned for Kite and SmartAPI, while Upstox is described as simpler token-based by some users. The failure mode traders fear is silent stoppage: the strategy runs but cannot place orders. Threads recommend refreshing before expiry, not after expiry. Session logic is treated as core infrastructure, not an edge case.

Rate limits and instrument caps shape strategy design

Users repeatedly cite rate limits because they decide whether multi-leg execution is feasible. Kite Connect is discussed at 3 orders per second, which can matter for complex baskets. SmartAPI and Upstox are both cited at 10 orders per second in multiple posts. For WebSocket subscriptions, users circulate caps like 3,000 instruments for Kite, 1,000 for SmartAPI, and 2,000 for Upstox. These numbers get interpreted as “how many things can I watch at once,” not just a technical detail. Traders also mention that WebSocket data is “less restricted” than REST market data requests, in the context of Kite. Some posts place tick latency broadly in the 100-300ms range from the exchange, calling it fine for swing trading but tight for scalping. The consistent advice is to size subscriptions, throttles, and sampling rates around the documented limits.

Response-time lists are popular, but traders add caveats

Social threads often share response-time tables to compare acknowledgement speed. One widely shared list shows Pocketful below 50 ms, Zerodha at 65-75 ms, Upstox at 55-65 ms, Fyers at 60-70 ms, and Angel One at 75-85 ms. Users present these as context rather than a promise of better fills. Several posts stress that market conditions dominate perceived speed during spikes. Some developers argue that stability and recovery matter more than shaving a few milliseconds. Others still track response time as a sanity check for regressions. The recurring warning is that broker claims and community tables should be validated live. Traders suggest testing specifically at 9:15 am and on expiry days.

Practical engineering checklist traders recommend before going live

Threads converge on a few non-negotiables: reconnection logic for WebSockets and automated token refresh. Developers recommend handling disconnects explicitly because “disconnects happen” even on popular APIs. Many also advise monitoring delayed order updates as a separate health signal. Rate-limit aware throttling is discussed as a way to prevent self-inflicted errors. Some users highlight sandbox testing, with Upstox often mentioned for having a built-in sandbox. Several posts also mention SEBI compliance discussions, including that systematic orders may need an Algo-ID tag per SEBI requirements. The operational message is consistent: test speed and stability when you actually trade, not mid-day in calm markets. Validate on live days, record error rates, and then choose the broker stack that matches your strategy’s tolerance for spikes.