No, you have full flexibility. AlgoDelta allows Direct Group Orders.

So, for that algodelta provides:

Bypass the Master: You can make Groups and place an order directly to the entire group.

Uniform Execution: This will send the same order to every child account in that group simultaneously, even if your Master account is doing something else.

So, how this works like when you stop a strategy, it no longer controls your trades. Any open positions from that strategy are exited right at point. After that, when you apply a new strategy, it starts fresh — meaning it will only take new trades based on its own signals.

So, in simple by removing the strategy the open trades in that are exited and with new strategy the trades will take entries by new signal.

Your concern is valid. If the broker session expires, your existing positions remain unaffected — they will stay open as they are.

However, placing any new orders will not be allowed until you log in again and refresh the session.

To avoid interruptions, it’s best practice to check your connections before the market opens and re-login quickly if a session expires during live trading.

No, it’s not compulsory to select the child and master are from same broker. You can select the for-example master as zerodha and child as angle one or vice versa in algodelta we have the flexibility of that.

If you want to know more, you can contact support team.

So, the requirement to login daily depends on the rules set by your broker and the way their API sessions are managed.

Some brokers enforce daily logins for security, while others may allow longer sessions.

Regardless of the specific rules, we suggest our users that before market opens, please come to the platform and ensure that all the accounts are connected or not by doing this your trades will flow without interruption.

Skipping the login could leave your master account disconnected.

Yes, so the multiplier is feature that multiples X times of master account quantity of trade to its child account.

So, for example – if your choice the 10 quantities of trade in master account and put the multiplier is 2 then the multiplied by 2 quantity is placed in child account that is 20 quantity will be placed in child account.

Yes, to solve this We have a specific feature for this called LTP Entry Trigger.

See for this we have the LTP entry what it does basically instead of direct entry, we will have the option that we can make the entry based on LTP.

so, if we set trigger to 100 then when the LTP reaches to 100 our platform enters the trade and immediately starts watching your Target (if you set suppose = ₹120) and Stop Loss (if you set suppose = ₹90) for you.

So that’s how we will solve this problem. For more you can explore our app.

You are right some brokers doesn’t give the direct per-tick volume we have to calculate that by comparing the tick cumulative volume with previous candle stored volume.

So, like that we will have to convert volume manually.

Below logic and code, you can refer.

Delta Volume = Current Volume – Previous Volume
Below code that you can refer:

def calculate_delta_volume(ticks):
    prev_volume = None
    result = []
    for tick in ticks:
        current_volume = tick["volume"]
        if prev_volume is None:
            delta = 0  # first tick
        else:
            delta = current_volume - prev_volume

            # safety check (in case of reset or bad data)
            if delta < 0:
                delta = 0
        tick["delta_volume"] = delta
        result.append(tick)
        prev_volume = current_volume
    return result

# usage
ticks = [
    {"price": 100, "volume": 1000},
    {"price": 101, "volume": 1200},
    {"price": 102, "volume": 1500},
]

output = calculate_delta_volume(ticks)

for t in output:
    print(t)

Later can use in the building candles from live data.

Yeah, this will happen in WebSocket because we have to send the heartbeat (ping) or reconnect logic.

You need 2 things:

Heartbeat (to detect dead connection)

Auto-reconnect logic

Below is the sample code you can refer:

import time
import threading

last_tick_time = time.time()
RECONNECT_TIMEOUT = 5  # seconds

def on_tick(tick):
    global last_tick_time
    last_tick_time = time.time()
    print("Tick:", tick)

def start_socket():
    print("Starting WebSocket...")
    # Actuall broket connect code
    # ws.connect()

def stop_socket():
    print("Stopping WebSocket...")
    # Actual close
    # ws.close()

def reconnect():
    print("Reconnecting...")
    stop_socket()
    time.sleep(1)
    start_socket()

def heartbeat_checker():
    while True:
        time.sleep(1)
        if time.time() - last_tick_time > RECONNECT_TIMEOUT:
            print("No ticks received. Connection seems dead.")
            reconnect()

# Start everything
start_socket()

threading.Thread(target=heartbeat_checker, daemon=True).start()

# Simulated tick loop
while True:
    time.sleep(2)
    on_tick({"price": 100})

Since, websocket are not 100 percent reliabile we need the heartbit or reconnect logic.

Yes, this will happen in the one minute candle data is used from the historical data.

Because, Camarilla (and most pivots) should not be calculated from one minute candles.

Correct approach:

You have to calculate pivot in the previous full day candle not the previous day one-minute candles.

Because the last candle close in the minute candle is different from the previous full day candle – just slightly different of some points but still the values in pivot will be inaccurate.

Below is the code that you can refer:

def camarilla_pivot(prev_high, prev_low, prev_close):
    diff = prev_high - prev_low
    
    levels = {
        "H1": prev_close + (diff * 1.1 / 12),
        "H2": prev_close + (diff * 1.1 / 6),
        "H3": prev_close + (diff * 1.1 / 4),
        "H4": prev_close + (diff * 1.1 / 2),
        "PP": (prev_high + prev_low + prev_close) / 3.0,
        "L1": prev_close - (diff * 1.1 / 12),
        "L2": prev_close - (diff * 1.1 / 6),
        "L3": prev_close - (diff * 1.1 / 4),
        "L4": prev_close - (diff * 1.1 / 2),
    }

    return levels

# Example (use previous day data of 1 day timeframe candle)
prev_high = 200
prev_low = 180
prev_close = 190

levels = camarilla_pivot(prev_high, prev_low, prev_close)
print(levels)

Ok, so don’t hardcode strikes — you calculate them using spot price and stick gap (step size).

As each stock has different strike gaps
ATM is just nearest rounded strike
ITM/OTM = shift from ATM
Simple approach in steps:

Get latest spot price
Round to nearest strike gap → ATM
Add/subtract gap → ITM/OTM
Can also refer the example code below:

def get_strikes(spot, strike_gap):
    atm = round(spot / strike_gap) * strike_gap

    strikes = {
        "ATM": atm,
        "OTM_CE": atm + strike_gap,
        "ITM_CE": atm - strike_gap,
        "OTM_PE": atm - strike_gap,
        "ITM_PE": atm + strike_gap,
    }

    return strikes

# Sample
spot_price = 19876 # Since spot price from the socket
strike_gap = 50  # NIFTY = 50, BANKNIFTY = 100

strikes = get_strikes(spot_price, strike_gap)

print(strikes)

Yes, so there’s no direct API that gives you “strike gap”.

The one way to do that calculate it from available strikes from the any source like script master file.

So, the simple idea is Strike gap = difference between consecutive strikes

Can understand with simple steps:

Fetch option chain / instruments
Take available strikes
Sort them
Find difference
Can also refer below code:

def get_strike_gap(strikes):
    strikes = sorted(set(strikes))
    if len(strikes) < 2:
        return None
    gaps = [strikes[i+1] - strikes[i] for i in range(len(strikes)-1)]
    # Most common gap
    gap = min(gaps)
    return gap

# Sample - Inplace of this have the stricks from instrument/option chain
strikes = [19800, 19850, 19900, 19950, 20000]

gap = get_strike_gap(strikes)
print("Strike Gap:", gap)

See in high volatility, the price “gaps” down. If your SL is a Limit order at 100, and the price jumps from 102 to 98, your order will never fill because the price is already below your limit.

This is because of the:

Price Gapping: In fast markets, the LTP (Last Traded Price) skips your specific Limit price.

SL-L vs SL-M: SL-Limit (SL-L) requires a specific price match. SL-Market (SL-M) triggers as soon as the price is hit, but many brokers now restrict SL-M for Options to prevent “freak trades.”

Fix is you have to use a range for SL – Limit orders, use wide difference between your Trigger Price and your Limit Price.

Another fix is buffer set trigger at your exit point but set Limit much lower to ensure it acts like a market order within a protected range.

def place_protected_sl(current_price, sl_points, is_buy=False):
    # Example for an existing BUY position (so we place a SELL SL)
    trigger_price = current_price - sl_points
    
    # Set limit price 1% lower than trigger to ensure execution in a crash
    # This creates a "price range" for the fill
    limit_price = round(trigger_price * 0.99, 1)
    
    order_params = {
        "symbol": "NIFTY25JAN22500CE",
        "qty": 50,
        "type": "STOPLOSS_LIMIT",
        "side": "SELL",
        "trigger_price": trigger_price,
        "price": limit_price # The "worst" price you'll accept
    }
    
    return order_params

# Input: Bought at 100, SL at 90
sl_order = place_protected_sl(100, 10)
print(f"Trigger: {sl_order['trigger_price']} | Limit: {sl_order['price']}")
# Result: Trigger 90, Limit 89.1 -> Order fills anywhere between 90 and 89.1

So, you can find it from the instrument list provided by broker.

Root idea is that broker gives the full instrument data (CSV/list).

We can filter it based on symbol, Strick, expire, option type (CE/PE).

So, the logic is simple we will select the most common Strick gap.

Below is the code you can refer:

def find_option(instruments, name, strike, option_type):
    filtered = []
    for ins in instruments:
        if (
            ins["name"] == name and
            ins["instrument_type"] == option_type and
            ins["strike"] == strike
        ):
            filtered.append(ins)
    if not filtered:
        return None
    # pick nearest expiry
    filtered.sort(key=lambda x: x["expiry"])
    return filtered[0]

# Sample instrument data
instruments = [
    {"name": "NIFTY", "strike": 19900, "instrument_type": "CE", "expiry": "2026-04-30", "token": 111},
    {"name": "NIFTY", "strike": 19900, "instrument_type": "CE", "expiry": "2026-05-07", "token": 222},
]

result = find_option(instruments, "NIFTY", 19900, "CE")

print(result)

Yes, this may be the issue of data consistency.

See may be the problem because of these factors:

Calculation on incomplete candles
Missing initial historical data.
Candle mismatch because of timing

See we need the both the live and historical data to get the accurate values in EMA and SMA.

Below is the code that you can refer:

def calculate_ema(prices, period=5):
    ema = []
    k = 2 / (period + 1)

    for i, price in enumerate(prices):
        if i == 0:
            ema.append(price)
        else:
            ema.append(price * k + ema[-1] * (1 - k))

    return ema

# This prices should be have the both live and historical data
prices = [100, 102, 101, 105, 107, 110]

ema_values = calculate_ema(prices, period=3)
print(ema_values)