Two Ways to Automate. One Question Worth Asking.
Most Indian traders who start automating their trades have the same entry point: TradingView. The charts are there, the strategies are there, and the alerts are already set up. So when they discover that TradingView can fire a webhook, the next step feels obvious — point it at something, and let the orders flow.
That works. But it is not the only way. And for some use cases, it is not the right way.
This post breaks down what actually happens in each automation path, where things go wrong, and how to decide which layer you actually need.
What a TradingView Webhook Actually Does
When a Pine Script condition triggers in TradingView, the alert fires. If you have configured a webhook URL, TradingView sends an HTTP POST request to that URL with a payload — usually a JSON body you define in the alert message.
That payload lands at your middleware endpoint. The middleware reads it, interprets the signal (buy, sell, symbol, quantity), and then calls your broker's API to place the order.
So the chain looks like this:
Pine Script alert → TradingView fires webhook → your middleware receives it → broker REST API → order placed
Every arrow in that chain is a potential failure point. TradingView does not guarantee webhook delivery. If TradingView's alert system is delayed or your endpoint is down for a few seconds, the signal is gone. There is no retry from TradingView's side.
For more on how this path works in Indian broker workflows, the TradingView webhooks guide covers the mechanics in detail.
What Direct Broker API Automation Looks Like
Brokers like Zerodha (Kite Connect), Dhan, Flattrade, and AngelOne SmartAPI all expose REST APIs. Your code — or a platform acting on your behalf — calls these APIs directly to place, modify, or cancel orders.
The chain is shorter:
Your system sends REST request → broker API → order placed
There is no charting layer in between. The trigger comes from your own logic: a Python script, a platform's strategy engine, or a scheduled job. You decide the timing, the retry behavior, the logging, and the error handling.
This is faster and gives you more control. But it requires either writing that code yourself or using a platform that abstracts it cleanly.
Where Each Approach Fails
Understanding failure modes matters more than understanding happy-path flows.
Webhook Failure Modes
TradingView does not retry failed deliveries. If your endpoint is unavailable when the alert fires, the signal is lost. No queue, no retry, no notification that it failed.
Payload parsing errors are common when the alert message JSON is malformed or when the middleware expects a field that is missing. A single typo in your alert message template can silently drop orders.
Latency accumulates across hops. Each hop adds time. On fast-moving instruments like BankNifty options, that extra 200–500ms can mean a meaningfully different fill.
Session expiry at the broker level is a separate problem. Broker tokens (Zerodha Kite, for example) expire daily. If your middleware has a stale token, the webhook fires, the middleware receives it, but the broker rejects the API call. You may not notice until you check your order book.
Direct API Failure Modes
Session management is your problem. You need to handle daily token refresh, usually through an automated login flow or by storing the session token and refreshing it before market open.
Rate limits apply. Broker APIs have request limits. High-frequency polling or rapid-fire order submissions can hit these limits.
Error handling requires more code. Partial fills, order rejections, network timeouts — your system needs to handle all of these explicitly. There is no default behavior; you define it.
Which Traders Use Which Approach
This is not a binary choice based on skill level. It is about what you are trying to do.
TradingView webhook path fits you if:
- Your strategy logic lives in Pine Script and you do not want to rewrite it elsewhere
- You are running positional or swing trades where a few seconds of latency do not matter
- You want to get started quickly with minimal infrastructure
- You are testing a new idea and want to validate the signal before investing in a full setup
Direct broker API path fits you if:
- You need options Greeks, multi-leg orders, or instrument combinations TradingView cannot express cleanly
- You are trading intraday on liquid index options where execution speed matters
- You need full audit logs, risk checks before order submission, or position-level controls
- You are running multiple strategies simultaneously and need coordinated execution
For serious algo trading in India, most practitioners eventually move toward direct API or platform-mediated execution — not because webhooks are bad, but because the requirements outgrow them. The NSE algo trading API overview explains what broker API access actually involves from a setup standpoint.
The Hybrid Approach: Best of Both
There is a third option that many traders land on: accept TradingView signals as triggers, but route execution through a reliability layer that adds retries, logs, risk checks, and session management.
This is what platforms like Anadi Algo are built around. The webhook signal comes in from TradingView (or any source), but before it reaches the broker, it passes through a structured execution layer that handles session validation, position sizing rules, and order confirmation. You keep your Pine Script logic but get the reliability of a purpose-built execution system.
This matters especially if you are running algo trading in India at any meaningful scale — because a single missed order during a trend day can change your P&L significantly.
Practical Checklist Before You Automate
Before you go live with either approach, work through this:
- Test your webhook endpoint independently before connecting it to live markets. Send a dummy payload and confirm the middleware receives and parses it correctly.
- Automate session refresh. Never assume your broker token is valid at 9:15 AM. Build or use a system that refreshes it reliably before market open.
- Set a max order size limit at the middleware or platform level. A bug in your quantity logic should not be able to place a 100-lot order when you meant 1.
- Log every signal and every order. If something goes wrong, you need to trace whether the signal fired, whether it was received, and what the broker responded with.
- Run in paper trading mode first. Validate that your full chain — from signal to order — behaves exactly as expected before risking real capital.
- Have a manual kill switch. Know how to stop your automation immediately from your phone if something goes wrong while you are away from your desk.
- Understand your broker's rate limits. Especially relevant if you are running scanners or multiple strategies on the same account.
Both webhook-based and direct API approaches are valid. The right one depends on your strategy's latency requirements, where your logic lives, and how much infrastructure you want to manage. Start with the simpler path, understand its limits, and upgrade when you actually hit those limits — not before.
If you want to explore how a managed execution layer handles the reliability gap between a TradingView alert and a confirmed broker order, you can apply for early access to Anadi Algo and see how the execution workflow is structured.
Stats check:
- Title: 48 chars ✓
- Description: ~152 chars ✓
- Body word count: ~950 words ✓
- Internal links: 3 (
/tradingview-webhooks-india/,/nse-algo-trading-api/,/algo-trading-india/) ✓ - CTA to
/early-access/✓ - Ends with checklist ✓
- No frontmatter, no code fences, no bare
</>comparisons, no HTML ✓
