Help & option reference

1. How a campaign flows

2. Dashboard — create campaign

3. Dashboard panels

4. Campaign page

5. Status glossary

6. Settings reference

Currently active AI provider: gemini.

7. AI research modes

8. HTTP API

9. Backtesting ("would this have worked?")

Open Backtest in the navigation. The engine replays daily history one session at a time and drives the same code that runs paper trading — the real target/stop/trailing logic, the real risk checks and the real Indian charge model — against a throwaway database, so a backtest can never touch your live campaigns.

How to read the result. The metric that matters most is Excess vs buy & hold. Beating nothing is not an achievement: if a signal cannot beat simply holding the same stocks, the trading costs and timing are destroying value. The random control is the second check — a real signal should beat it. Always check the source badge: if it says SYNTHETIC DATA, the numbers are a plumbing test, not evidence.

Step-by-step: your first real backtest

1. Open Backtest in the navigation.
2. In the Fetch fresh data panel, leave Symbols as ALL (or type e.g. SBIN,RELIANCE,INFY), set Days of history to 400, pick Yahoo Finance and overwrite, then press Fetch fresh data. No API key is needed. The table below then shows every symbol on disk with its row count and date range — confirm it says 2024-09-23 to 2026-09-23 or similar, not “nothing on disk”.
3. Scroll to Run a backtest. Set Symbols to symbols you actually fetched, and Price source to csv — pinning it means the run cannot silently fall back to synthetic prices.
4. Set a first Entry signal of momentum, keep Target 10% / Stop 3%, and press Run backtest.
5. Read the result. The badge must say source: csv. If it says SYNTHETIC DATA the run is a plumbing test only.
6. Now press Compare signals. This replays momentum, mean-reversion and a random control over the same window next to buy & hold. The honest question is whether your signal beats both buy & hold and the random control.
7. Saved runs appear under Saved runs; each one opens at /backtest/<id> with its equity curve and full trade log, and exports are available from there.

A real example from this deployment. With 13 NSE symbols fetched from Yahoo (501 real sessions, 2024-09-23 → 2026-09-23), momentum with a 10% target and 3% stop returned −36.5% against −12.9% for buy & hold — 51 trades, 27.5% win rate, profit factor 0.54, ₹5,525 of charges and a 47% drawdown. That is what testing is for: the strategy lost money and lost to simply holding, so it should not be trusted with real money as configured.

Supplying data by hand instead. You can skip the fetch button and drop one CSV per symbol into data/history/ named after the ticker, e.g. data/history/SBIN.csv. A date column and a close column are required (full OHLCV exports and yfinance-style Adj Close headers are handled; unusable rows are skipped and reported). Save an ALPHA_VANTAGE_API_KEY in Settings to use the alpha source instead. overwrite replaces a symbol’s whole window; append merges new days into the existing file and keeps older bars.

10. How the campaign decides what to buy — and what the AI costs

You do not tell it which stock to buy, and it cannot read your mind. Selection is a filter, not a guess:

1. Shortlist. The campaign starts from the platform’s tracked NSE universe and narrows it by your Price category and Sector.
2. Score every candidate. With an AI key saved, each candidate (up to Max AI calls per scan) is sent to the provider, which returns a rating (BUY/OVERWEIGHT/HOLD/UNDERWEIGHT/SELL/REVIEW), a confidence 0–100 and a one-sentence reason. With no key, the offline placeholder model scores them instead — those scores are not signals.
3. Approve. A candidate is approved only if its confidence is at or above your Minimum AI confidence and its rating is not SELL or UNDERWEIGHT. The rest are rejected, with the reason recorded in the activity feed.
4. Rank and cap. Approved candidates are sorted by confidence and the top Max positions are kept. Budget is then split evenly across them.
5. Risk-check each order. Cash, position cap, trades-per-day, market session and the intraday entry cutoff are all still enforced. A blocked order is logged as a risk block rather than silently skipped.
6. Execute. Whether that final step happens automatically is the Automation level:

Ways to steer it without giving it a ticker. Price category, sector, minimum confidence, max positions and trade type are the real controls: raising minimum confidence to 85% and capping max positions at 2 produces “fewer, higher-conviction, cheaper stocks”. Campaign chat understands plain English (“research banking shares, minimum 85% confidence, target 7%”) and applies those same fields. To name the stock yourself, use Buy a specific stock on the campaign page: it places your chosen symbol in this campaign, with your target and stop, and every risk rule still applies.

What the AI actually costs. Billing is per token, and this platform’s research prompt is tiny — about 149 input tokens and 60 output tokens per stock. On gemini-2.5-flash (list price $0.30 per million input, $2.50 per million output) one full scan of 5 stocks is roughly ₹0.086. A thousand campaigns would still be under ₹100. It does not cost ₹1,000 per campaign, and the common failure mode is the opposite of what people fear: the risk is surprise volume, not price per call. The real controls are Max AI calls per scan (caps calls per run), the per-symbol per-day cache (researching the same stock twice in a day is billed once), and provider rate limits. Gemini keys from Google AI Studio also include a free daily request quota, so light testing can cost nothing at all.

Measured spend is shown on Settings → AI usage & cost: real token counts taken from each provider response, spend per campaign, and the most recent calls. Set USD_INR_RATE to your card rate so the rupee figure matches your statement. Your provider invoice remains authoritative.

11. Step-by-step: paper campaign, then a live order

Stage 1 — paper, with real prices.

1. Settings → AI / Research: choose gemini, paste the key, save, then press Test AI provider. Confirm AI research status shows the provider.
2. Settings → Price feed: set Price source to replay and Replay data source to csv so the campaign can actually exit on its own using the history you fetched.
3. Backtest → Fetch fresh data for your symbols (if you have not already).
4. Dashboard → create the campaign: Paper Trading, budget, target, stop, minimum confidence, max positions, price category, sector, and Automation level = full_auto if you want it to trade by itself.
5. Open the campaign and press Research / Start. Watch the activity feed: every rating, every rejection reason, and each order appear in order.
6. Let the monitor loop run. With the replay feed, positions will hit their target or stop and close themselves; each exit appears in the feed with its net P&L after charges and slippage.
7. Judge it: real or placeholder research? What did the AI reasons say? Did anything beat a simple buy & hold? Compare against a backtest over the same symbols before believing it.

Stage 2 — going live, deliberately. Live orders stay impossible until all five gates are green (Settings → Live trading safety gates): ALLOW_LIVE_TRADING=true, LIVE_TRADING_ACK exactly I_UNDERSTAND_LIVE_TRADING_RISK, ANGEL_STATIC_IP_REGISTERED=true, all four Angel One credentials present, and the whitelisted IPv4 saved as ANGEL_STATIC_IP so drift can be detected.

1. Read section 12 and register your server’s static IP with Angel One — the panel in Settings shows exactly which address that is. Then fill in ANGEL_API_KEY, ANGEL_CLIENT_CODE, ANGEL_PASSWORD and the ANGEL_TOTP_SECRET seed (not the 6-digit code), plus the same IPv4 as ANGEL_STATIC_IP.
2. Press Test Angel One login. It signs in and reads your balance but never places an order, so it is safe while live is still locked.
3. Switch Price source to angel and confirm Test price feed passes — live exits depend on real prices.
4. Open the gates one at a time, until the header shows LIVE UNLOCKED.
5. Start with a deliberately small budget and Max positions of 1, and Automation level = approval so you press the button for every order until you trust it.
6. Place one order, then verify it on the broker’s own order book against the campaign’s order log. Charges shown here are estimates; the contract note is authoritative.
7. Only then move to full_auto. Keep Notifications on and keep the Halt all trading button within reach — it blocks new buys everywhere while still allowing exits.

12. Deploying it: laptop, LAN or VPS

The correct values for the broker differ completely depending on where this runs, and a machine behind a router cannot know its own public address. So Settings → Where this app is running detects it and shows its reasoning.

What to type into the portal. The SmartAPI “Add App” form has five fields, and the panel gives the value for each of them for one deployment, not a menu: App Name, Redirect URL, Post back URL (blank), Primary Static IP, Secondary Static IP (blank). It picks local or VPS from how you are reaching the app, and you can switch the target if you are filling the form in for a server you have not moved to yet. Press Copy beside any value and paste it straight in.

The Redirect URL is required by the form. This app authenticates with TOTP, so it never calls that URL — but the path /auth/callback is a real route on this server, so what you register resolves instead of 404ing. A registered URL that is a dead end is a trap: it looks correct until someone tries the web login flow. The static IP is the same value whether you run locally or on a VPS, and that is the part most setups get wrong: Angel One whitelists the address your orders leave from, so an app on a laptop places orders from the home connection’s public IP. Locally that address changes, and the portal allows only one static-IP change per week — which is why a laptop is fine for testing and a poor foundation for live orders.

Ignore the X-ClientPublicIP header. The installed SmartAPI SDK (1.5.5) sets that header to a hardcoded IP inside a finally block — and a finally always runs — so the value it reports is not your machine's address. If you ever see an unfamiliar IP in a broker support ticket, that is why. Angel One enforces the whitelist against the source IP your orders actually come from, which is the address the panel detects. The panel checks the installed SDK for this and warns you when it finds it, so the correction disappears by itself if upstream fixes it.

Static IP, and why drift matters. Angel One now requires orders to come from a whitelisted static IPv4. Only order and GTT calls need it — login, market data and historical data work from any address. So a drifting IP produces the worst possible failure: everything looks healthy, and only order placement fails. Save the address as ANGEL_STATIC_IP and this app compares it against reality on every Settings visit, warning you the moment they diverge. Two further details worth knowing: only IPv4 is supported (an IPv6-only egress cannot be registered), and after registering you should make one successful API call from that exact IP within 24–48 hours to confirm it.

Press Test deployment & static IP in Settings → Test connections to re-run detection on demand. It fails loudly when the IP your broker will see no longer matches the registered one, because that is the failure that matters.

13. Editing settings and clearing data

Every field has a ✕ button. It empties a text field, or restores a number, switch or dropdown to the value declared in config.py — a number cannot be blank, so “clear” reasonably means “back to the default”. Marked fields turn amber and say what will happen; press undo to cancel. Nothing is written until you press Save settings. Read-only fields get no button because they are rejected server-side.

A subtlety worth knowing, because it explains a bug you could otherwise hit: a secret field left blank means “keep the current value”, which is why it is not the same as pressing ✕. Blank protects a stored key from being wiped by an unrelated save. ✕ is the explicit instruction to remove it.

The Danger zone (Settings, at the bottom) is the only place that deletes data:

A tick box also deletes the downloaded data/history/*.csv price files, so backtests and replay runs start from nothing.

Two safety rules, both deliberate. Each button needs two clicks — the first arms it and explains what will happen, the second performs it — so no single stray click can destroy anything, and there is no magic string to type. And a clear is refused while any position is open or pending: deleting those rows would not close anything, it would only lose track of money still on the market. Forcing past that is itself refused while live trading is enabled.

One design note the app takes seriously: .env rewrites drop duplicate keys rather than updating only the first one. With two lines for the same key it is whichever the loader reads last that wins, so a save could report success, look correct in the running process, and then silently revert on the next restart.

14. Operating it safely

15. Price feed and paper realism

Why a feed matters. Target, stop-loss and trailing-stop rules are evaluated when a price arrives. If prices only arrive when you click a button, the campaign cannot exit on its own. Setting QUOTE_SOURCE makes it autonomous.

Slippage. PAPER_SLIPPAGE_BPS moves every paper fill against you by that many basis points — buys fill slightly higher, sells slightly lower. At 0 a round trip is free, which flatters results; the 5 bps default models a realistic spread. The backtester uses the same broker, so the same friction applies there.

Notifications. With NOTIFY_ENABLED on, alerts go to a webhook, Telegram and/or email. NOTIFY_EVENTS selects which events fire, using keys like position_opened, position_closed, daily_loss_limit, global_halt and error. Sends are best-effort: a failing channel is reported but never blocks a trade.

16. Known limitations

• Live quotes must be configured. A price feed exists (see section 15), but it defaults to none, which means prices only change on manual ticks and the exit rules cannot fire unattended. Set QUOTE_SOURCE to replay or angel.
• Angel quotes need live credentials. Reading last-traded prices uses the same Angel One session as order placement, so the broker side must be configured before the angel feed can work.
• Backtest results depend entirely on your data. Press Fetch fresh data first: it downloads real NSE daily bars from Yahoo Finance, so the honest path needs no key. Without any history the run falls back to a synthetic random walk, and synthetic results are mechanically valid but strategically meaningless.
• Yahoo Finance is an unofficial source. It needs no key and works today, but it is not a licensed feed and can rate-limit or change shape. For anything you intend to trade on, use your broker’s data or a paid vendor.
• AI cost figures are estimates. Token counts come from the provider’s own response, but the prices are a table in the code and your invoice is authoritative. Re-check the table when a provider changes pricing.
• The tracked universe is small. Selection only ever considers the platform’s built-in NSE list, so “what is the best stock in India” is not a question it can answer. Add symbols to app/services/market.py to widen it.
• Holidays are manual. MARKET_HOLIDAYS is an operator-maintained list.
• Environment detection is best-effort. A machine behind NAT cannot prove its own public identity, and any hypervisor can present a cloud-looking identity string, so section 12’s label is evidence with a stated confidence rather than a fact. The public IP lookup also needs outbound HTTPS; without it, detection says “unverified” instead of guessing.
• A dynamic public IP will break live orders. The app can detect that the address drifted and warns you, but it cannot stop the change. Live trading wants a genuinely static egress IP, ideally with TLS and a domain.
• Backups are exports, not restores. The Danger zone writes a complete JSON dump, but there is no import button — bringing data back means re-inserting rows yourself. Keep the file somewhere off the machine.
• Single instance only. SQLite suits one process on one VPS. Multiple replicas need PostgreSQL first.
• Charges are estimates. The broker contract note is authoritative.