The Algo Trader’s Dilemma: Nubra API vs Zerodha API

Zerodha Kite Connect Authentication#

When you build live trading systems, the first bottleneck isn’t latency — it’s login.

Zerodha’s Kite Connect follows a manual authentication loop:

1. Open a browser
2. Log in manually
3. Complete 2FA / OTP
4. Capture redirect URL
5. Generate a request token

This token expires daily, meaning:

• A human must log in every morning
• Headless server deployments are fragile
• Fully automated systems break without intervention

Nubra Authentication#

Nubra skips the browser entirely.
Authentication happens directly inside your code using the SDK:

from nubra_python_sdk.start_sdk import InitNubraSdk, NubraEnv

# Initialize the Nubra SDK client
nubra = InitNubraSdk(NubraEnv.PROD)

For developers running algos on VPS or servers, Nubra also supports TOTP-based login — meaning you can generate a time-based authentication code once, store credentials in a .env file, and run fully automated logins without any human input.

Zerodha WebSocket Tick Stream#

Zerodha’s WebSocket streams raw exchange-level tick data — exactly as received from the exchange.

This data requires preprocessing, symbol mapping, and cleanup before it can be used in a trading model.

Developers must then write separate code modules to calculate analytics like:

• Implied Volatility (IV)
• Delta
• Theta
• Vega

This makes the overall workflow slower and more complex.

Zerodha Tick Stream Example:

{
    'tradable': True,
    'instrument_token': 12212994,
    'last_price': 398.65,
    'volume_traded': 7404225,
    'ohlc': {
        'open': 288.05,
        'high': 419.7,
        'low': 230.15,
        'close': 302.95
    },
    'oi': 1303275,
    'depth': {
        'buy': [
            {'quantity': 375, 'price': 397.25},
            ...
        ],
        'sell': [
            {'quantity': 300, 'price': 398.05},
            ...
        ]
    }
}

Nubra WebSocket (Analytics-Enriched Stream)#

Nubra delivers tick-level data enriched with analytics.

Its WebSocket stream includes:

• Live option Greeks
• Order book details
• Market depth

All delivered as structured, ready-to-use Python objects.

This removes the need for additional preprocessing or analytical computation, letting developers focus entirely on strategy logic and execution.

Nubra (Options Greeks) Stream Example:

OptionData(
    ref_id=942993,
    strike_price=2350000,
    lot_size=75,
    last_traded_price=242935,
    delta=0.9967,
    gamma=4.97e-05,
    theta=-0.7176,
    vega=0.2772,
    open_interest=0,
    volume=1275
)

“Delta-Neutral Short Strangle: Two Paths, One Strategy”#

A delta-neutral short strangle involves selling one out-of-the-money call and one out-of-the-money put such that the combined delta of both legs is approximately zero.

This strategy profits from time decay (positive Theta) and benefits when implied volatility (IV) drops.
While the concept is simple, implementation complexity varies dramatically depending on the platform you use.

Let’s see how the same strategy looks when built on Zerodha’s Kite Connect vs Nubra’s SDK.

Strategy Deployment on Zerodha#

Zerodha (Kite Connect): Manual Multi-Leg Execution

• Operates at a per-leg level — each option leg (Call, Put, Stop-Loss) requires a separate REST API call.
• Tick data from WebSocket arrives raw and unstructured, requiring preprocessing and cleaning before analytics.
• Greeks and implied volatility must be calculated manually using external code or libraries.
• Strike selection for a short strangle depends on these custom-computed Greeks.
• Execution is sequential — each order (sell, stop-loss, target) is placed and confirmed independently.
• Requires constant monitoring of each leg’s PnL and delta exposure.
• Exit logic such as OCO (One Cancels Other) or combined target/stop-loss handling must be manually coded.

This modular setup offers flexibility but adds latency, execution risk, and infrastructure complexity.

Strategy Deployment on Nubra#

Nubra (Flexi Basket SDK): Unified Multi-Leg Execution

• Treats the entire strategy as one basket, not individual legs.
• Uses a single Flexi Basket Order to execute multiple legs (call + put) in one atomic transaction.
• All parameters — entry price, stop-loss, and target — are defined at the basket level, not per order.
• Built-in OCO logic and risk management automatically handle exits and cancellations.
• Streams real-time analytics (Greeks, IV, deltas) directly via the SDK — no preprocessing needed.
• All legs update in real time within the basket; PnL and risk are tracked collectively.
• Reduces API load and latency by eliminating redundant API calls.

This architecture minimizes latency, removes operational overhead, and lets traders focus purely on strategy design and logic.