Working with Indian broker APIs

Most Indian broker APIs expose broadly the same surface: authenticate to get a token, subscribe to a WebSocket for live prices, place and manage orders over REST, and reconcile positions. The differences that matter are rarely in the documented endpoints. They show up in the daily login flow, the rate limits, and what happens when something goes wrong mid-session.

Authentication is the first thing that will break

Indian broker APIs generally issue access tokens valid for a single trading day, and the token-generation step typically involves an interactive login with two-factor authentication. This is a deliberate regulatory posture, not an oversight, and it has a direct consequence: a genuinely unattended, fully hands-off system is harder to build here than the API documentation implies.

In practice you design around it. Treat token acquisition as a distinct pre-market step that runs before the session and writes the token somewhere your trading process reads at startup. Store it outside your code — an environment variable, a secrets store, or a short-lived cache entry. Assume the token can be invalidated mid-session and handle the resulting authentication failure as an expected event rather than a crash.

# Treat auth failure as an expected state, not an exception path
async def place_order(client, payload, *, retries=2):
    for attempt in range(retries + 1):
        resp = await client.post("/orders", json=payload)
        if resp.status_code == 401 and attempt < retries:
            await client.refresh_token()
            continue
        if resp.status_code == 429:
            await asyncio.sleep(2 ** attempt)  # back off, do not hammer
            continue
        return resp
    raise OrderFailed(payload)

Note the backoff on a rate-limit response. A naive retry loop that immediately re-fires on failure is the most common way a modest strategy accidentally emits hundreds of orders in a few seconds.

Market data: WebSocket, not polling

Every major Indian broker offers a binary WebSocket feed for live quotes, and you should use it. Polling a REST quote endpoint is slower, burns your rate limit, and gives you a worse picture of the market. The feeds typically offer tiered modes — a lightweight last-traded-price mode, and heavier modes carrying full market depth. Subscribe to the lightest mode that satisfies your strategy; depth data is significantly more bandwidth and most strategies never read it.

The operational details that actually cause incidents:

• Subscription limits. There is a ceiling on instruments per connection. Strategies that scan a wide universe need either multiple connections or a filtered watchlist.
• Reconnection. Feeds drop. Your client must reconnect with backoff and re-subscribe on reconnect — a reconnect that forgets its subscriptions produces a silent feed, which is far more dangerous than a visible crash.
• Instrument tokens change. Contracts are identified by numeric tokens, and these are refreshed periodically. A hardcoded token will eventually point at the wrong instrument or nothing at all. Download the instrument master daily and resolve symbols at startup.
• Ticks are not candles. The feed gives you a stream of trades, not neat OHLC bars. If your strategy works on candles, you are responsible for aggregating them correctly and for deciding what a candle means when no trade occurred in the interval.

Orders and the reconciliation problem

Placing an order is easy. Knowing what happened to it is the hard part. An order can be accepted by the broker and rejected by the exchange moments later. A confirmation can arrive after your logic has already moved on. A network failure can leave you genuinely uncertain whether an order was placed at all.

The rule that avoids most of this pain: never treat your own intent as the truth about your position. The broker's reported position book is the truth. Your system should reconcile against it — at startup, periodically through the session, and always after any error. A strategy that believes it is flat while holding an open position is how a small bug becomes a large loss.

It is also worth being deliberate about idempotency. If a request times out, you do not know whether it arrived. Re-sending blindly risks a duplicate position; assuming failure risks an unmanaged one. Tagging orders with your own identifier and querying before retrying resolves the ambiguity.

Choosing between brokers

For automation specifically, the differentiators worth weighing are the cost of API access, whether historical candle data is included or charged separately, the documented rate limits, WebSocket stability under load, and how the daily authentication flow works. Most comparisons focus on brokerage rates, which matter far less to an automated system than a feed that stays connected and an order API that behaves predictably under stress.

Specific pricing, limits, and endpoints change often enough that any figures quoted here would be stale before long — check each broker's current API documentation directly. The architectural advice does not change: build for token expiry, rate limits, reconnection, and reconciliation, and the specific broker becomes a detail you can swap.