Broker API checklist for Indian algo traders (2026)

Social media threads from Indian retail algo traders have converged on a clear “broker API checklist” for selecting a platform and running strategies reliably. The discussion is less about flashy features and more about avoiding operational failures once real money is deployed. Most checklists start by verifying order execution via REST APIs and live market data via WebSocket streaming. The same threads repeatedly warn that missing basics such as reconnection logic or token refresh can break a strategy mid-session. Another recurring theme is that compliance is no longer optional, with static IP whitelisting and mandatory 2FA becoming standard requirements. Traders also frame API costs as part of reliability budgeting, since some brokers charge a monthly fee irrespective of usage. Below is a consolidated view of what is trending across Reddit and developer groups.

1) Start with the three non-negotiables

Community guidance says every systematic strategy needs three capabilities from the broker interface: order placement, market data, and portfolio monitoring. For order placement, REST endpoints are considered the baseline because they fit neatly into request-response workflows. For market data, WebSocket streaming is repeatedly described as mandatory for live price feeds. For portfolio monitoring, endpoints like positions are treated as essential because strategies need an internal view of exposure and P&L. Traders also check that the API design supports both real-time decisions and post-trade reconciliation. Many checklists explicitly separate “market data reliability” from “order execution reliability” because the failure modes are different. If you plan to automate TradingView alerts, posts note you will typically need a bridge or middleware to connect alerts to the broker API. A small set of commonly referenced endpoints looks like this.

2) Documentation quality is treated as a feature

Across Reddit threads, documentation quality is ranked alongside uptime and latency. The logic is simple: poor docs translate into production bugs and longer debugging cycles. Developers repeatedly mention that ambiguous parameter rules or incomplete error descriptions cause avoidable order failures. When multiple strategies share the same execution stack, small integration mistakes can create repeated failures at scale. Traders therefore look for docs that clearly explain authentication, order workflows, and edge cases like rejections. They also value examples that match real flows, not just “hello world” snippets. A consistent complaint in forum discussions is that weak docs force engineers to learn by trial and error during market hours. In checklist terms, “read the docs” becomes “verify the docs cover your failure cases.” Many users treat strong documentation as an early proxy for how mature the API programme is.

3) Rate limits decide whether scaling is practical

Rate limits matter far more once you run more than one strategy or need to fire multiple orders quickly. Threads emphasise designing around rate caps, rather than hoping your broker will allow bursts. A commonly cited operational issue is hitting rate limits when multiple components request quotes, positions, and order status in parallel. Community guidance specifically calls out designing for “429” errors instead of treating them as rare events. Traders suggest retries, but with a limited number of attempts rather than looping indefinitely. They also warn that your architecture should throttle requests so a noisy module does not starve critical order placement. Several posts reference staying within rate limits such as 10 orders per second and planning your order flow accordingly. Under SEBI’s threshold, staying below 10 OPS is described as the line for being considered a regular API user rather than an algo trader. Even then, posts note such strategies are still treated as algos and must execute through a predefined API key.

4) WebSocket is mandatory, but reconnect logic is your job

Forum checklists repeatedly say WebSocket support is non-negotiable for live price feeds. At the same time, traders warn that disconnects happen and you must build reconnection logic. In practice, the “reliability work” moves into the client side, not the broker side. Posts recommend tracking connection state and re-subscribing to instruments after reconnecting. A common suggestion is to queue orders during disconnections, then reconcile once connectivity returns. The goal is to avoid partial state updates where your strategy thinks it placed an order but the broker never received it. Several developers stress that market data and trading sessions should be monitored separately because one may fail while the other stays up. Error handling practices include catching exceptions, logging them with timestamps, and retrying in a controlled way. Traders also recommend validating that your WebSocket feed and REST quote endpoint stay consistent during recovery periods.

5) Authentication and token expiry are reliability-critical

Authentication details are treated as a first-class reliability concern, not a paperwork step. Many traders point out that session tokens expiring daily can break strategies if refresh is not automated. One widely shared example is the Zerodha Kite Connect flow where a request token is exchanged for an access token. Posts state that the access token is valid for one trading day and you must re-authenticate every morning before market opens. Mandatory OTP or 2FA on all sessions is repeatedly mentioned as part of the new compliance reality. Threads also reference auto-logout requirements before each trading day begins, which affects how you schedule login and token refresh. Because of these constraints, a well-maintained Python library is frequently cited as a practical advantage. The reason given is that libraries reduce implementation errors in authentication and order workflows. Traders still caution that using a library is not a substitute for understanding token lifecycles and failure handling.

6) Historical data depth supports SEBI-aligned validation

Historical data depth comes up often because retail traders are emphasising backtesting and risk validation before going live. Several posts frame this as part of “SEBI-aligned workflows,” meaning you should be able to justify how your strategy was tested. The checklist therefore includes verifying what historical data is available and how you can access it reliably. Developers also look for consistency between historical data formats and live feed formats to reduce mapping errors. In community discussions, historical coverage is treated as more than convenience because it affects whether you can validate drawdowns and position sizing rules. Traders mention that operational readiness includes being able to reproduce a decision path from data to signal. This ties directly into audit trails and structured logs discussed in compliance threads. A practical takeaway is that broker choice is not only about order speed, but also about the quality and depth of data required for validation. If you use third-party bridges for signals, traders still want a clean data trail from the broker side for verification.

7) Strategy and order-handling pitfalls discussed online

At the strategy layer, posts repeatedly emphasise accounting for latency between signal and execution. The reason is that the gap can change whether the signal is still valid when the order hits the market. Traders advise treating latency as an input to your design, not an afterthought. At the order-handling layer, correct handling of partial fills and rejections is highlighted as essential. Many threads warn against assuming an order is either fully filled or fully failed, because partial states create exposure mismatches. Infrastructure readiness is also part of the checklist, including planning for internet, broker, or exchange outages, not just local machine issues. Monitoring is treated as a mandatory layer, with real-time alerts for order failures described as essential. Community checklists also insist on a manual override or kill switch to stop trading instantly. Logging practices include timestamped entries and structured storage, so incidents can be reconstructed later. The overall message is that “execution plumbing” often determines real outcomes more than the strategy logic.

8) SEBI compliance items now sit inside the API checklist

Several posts cite a SEBI circular from 2023 stating that retail algos must be registered and approved by the stock exchange through the broker. Threads also say all algorithms must run through a SEBI-registered broker’s API, and that using a compliant platform and broker keeps you within the law. Static IP whitelisting is repeatedly described as mandatory, with API order placement originating only from whitelisted static IP addresses registered with the broker. Dynamic IPs, including home broadband, mobile data, or office WiFi, are described as not permitted for order placement via API. Posts add that clients are allowed to provide a maximum of two static IPs, mapped to their API keys, and for user-developed algos the static IP must belong to the client. Indian server hosting is also mentioned as a requirement for retail algos, alongside 5-year log retention by brokers for detailed API activity. Another operational change discussed is that non-compliant brokers were barred from onboarding new API clients from January 5, 2026. Traders recommend completing KYC, enabling API access in broker settings, obtaining a static IP, and getting whitelisted as the first operational steps.

9) Broker API options and cost considerations traders cite

Social discussions include comparisons of popular broker APIs based on language support, monthly cost, and rough order speed ranges. Cost is framed as part of reliability budgeting because fixed monthly fees can change how you plan redundancy and environments. Traders also note that a maintained Python library reduces the chance of errors, so language support is not just a developer preference. While order speed is discussed, most checklists still prioritise correct handling of authentication, rate limits, and disconnect recovery. Zerodha’s Kite Connect is frequently described as popular with strong documentation, but it also has a stated monthly fee. Other brokers are discussed as lower cost options, including several with free API access in community comparisons. Separately, posts about 2026 compliance say static IP registration is now required across APIs, so “ease of onboarding” includes the IP whitelisting workflow. For high-frequency patterns, traders repeatedly return to the 10 OPS line and the need to design conservatively around it. Here is the broker comparison table shared in multiple threads.