Handling broker API changes

Direct answer to "what happens if the broker API changes or throttles" — this is not hypothetical; every broker has deprecated fields, changed rate limits, discontinued order types (chapter 52's BO discontinuation is a real historical example), and occasionally had extended outages.

Pin your SDK version, upgrade deliberately

pip freeze | grep kiteconnect
# kiteconnect==5.0.1

# requirements.txt
kiteconnect==5.0.1

Never let pip install --upgrade run unpinned in production — an SDK major version bump can change method signatures, response shapes, or exception types without warning your running bot until it breaks mid-session.

Version pinning doesn't protect you from server-side changes

Unlike client SDK versions, the broker can change server-side behavior (new required fields, changed rate limits, deprecated endpoints) independent of your pinned SDK version. Mitigate with:

def validate_api_contract(kite):
    """Run at startup — fail fast if a critical assumption no longer holds."""
    profile = kite.profile()
    required_fields = {"user_id", "exchanges", "products"}
    missing = required_fields - profile.keys()
    if missing:
        raise RuntimeError(f"Broker API response missing expected fields: {missing} — API may have changed")

Zerodha publishes API changes and deprecation notices via kite.trade/forum and developer mailing lists — check periodically, and before any planned SDK upgrade. This is unglamorous but is literally how you find out about a breaking change before your bot does, in production.

Rate limit changes — build in headroom, not exact compliance

If you build your throttling (chapter 20) to sit exactly at today's documented limit, a limit reduction (which brokers have done during high -load periods, e.g. results season or extreme volatility days) breaks you immediately. Build in comfortable headroom (e.g. operate at 60-70% of documented limits) so a moderate tightening doesn't require an emergency code change.

Graceful degradation, not a hard crash, on unexpected API responses

def safe_get_margins(kite) -> dict | None:
    try:
        return kite.margins(segment="equity")
    except Exception as e:
        logging.error(f"Unexpected margins() failure, possibly API change: {e}")
        send_alert(f"margins() call failing unexpectedly: {e}", urgent=True)
        return None   # caller must handle None — never assume this always succeeds

Every call site that consumes broker data should have an explicit "what if this returns something unexpected" path — not because you expect it often, but because the failure mode when it does happen unhandled is a crashed bot mid-session, at exactly the moment you most need it running correctly (e.g. holding open positions).

The broader lesson: broker dependency is a real, permanent risk, not a one-time setup cost

This is worth internalizing as a standing risk category alongside market risk — your strategy's actual reliability is capped by your broker relationship's reliability, and no amount of good strategy design fixes a broker-side outage or breaking change. Build monitoring (chapter 92) and conservative fallback behavior assuming this will eventually happen, not as a rare edge case.

Next: 095 — Backup, recovery, and state persistence