Webhooks vs Polling for Market Data: What’s the Difference?
Blog by Aliceblue News Desk
30 October 2026
9 minutes
Say you’ve written a small script to track 5 stocks, and it works well. You stretch it to 50, and now it throws errors and sometimes goes quiet. Usually the logic is fine. The trouble is how often the script asks your broker for data.
That’s what webhooks vs polling for market data is about. Polling means your program keeps asking for news. A webhook means the broker tells you when there’s news. This guide shows how each works, what broker limits do to a real setup, and why many traders end up using both.
Table of Contents
Quick Answer
Polling means your program asks the broker for data at fixed gaps, such as every 5 seconds. A webhook means the broker sends a message to your program only when an event happens, like an order getting filled. Polling is easier to build but uses many requests. Webhooks use few requests but suit events, not live prices. Live prices usually come through a WebSocket.
What Is Polling and What Is a Webhook?
Polling means repeating the same question on a timer. Your program asks, “What’s Reliance trading at?” every few seconds, whether or not the price moved.
A webhook works the other way round. You give a service a web address (a URL) where your program listens. When something happens, the service sends a message to that address.
Think of a train ticket on the waiting list. Refreshing the page to check your status is polling. Getting a message the moment your status changes is a webhook.
Programs talk to brokers through an API, which is a set of rules that lets one program ask another for data or place orders.
Brokers limit how many requests you can send, so your choice affects how well your tool runs. Zerodha’s Kite Connect calls its webhooks postbacks and sends one to your registered URL when an order’s status changes. TradingView alerts can also send a webhook, and third-party tools such as AlgoDelta use that to place orders with brokers, Alice Blue included.
How Do Webhooks and Polling Work?
Polling
- Your program asks the broker for the latest price.
- The broker replies with the price, volume, and the day’s high and low.
- Your program checks it against your rule, for example, “alert me above ₹1,350”.
- It waits for the gap you set, say 5 seconds.
- It asks again, even if nothing changed.
Webhook
- You register a URL where your program can receive messages.
- An event happens, such as an order getting filled or rejected.
- The service sends a message with the details to your URL.
- Your program reads it and acts, for example by saving the trade or alerting you.
- Your program replies “received” so the service knows it got through.
Where does a WebSocket fit?
Prices change several times a second, so neither method is a good match. A WebSocket is a persistent connection, and the broker pushes prices through it. It’s the usual route for a real-time market data API.
Alice Blue’s WebSocket documentation covers the setup. It advises sending a heartbeat every 50 seconds, which is a small ping that tells the server you’re still connected. Without it, the server may close the connection if no data moves for a while.
Example: Tracking 50 Stocks
Take a stock with F&O contracts, like Reliance. Since 3 August 2026, such stocks trade continuously from 9:15 AM to 3:15 PM, which is 6 hours or 21,600 seconds. Say you track 50 of them and send one request per stock every time you poll.
An independent review of Alice Blue’s API documentation (September 2026) lists these API request limits: 5 quote requests a second, 300 data requests a minute, 3,000 an hour, and 2,00,000 a day. Limits can change, so confirm them in the API documentation.
Polling gap | Requests per minute | Requests per hour | Requests per day |
Every 30 seconds | 100 | 6,000 | 36,000 |
Every 60 seconds | 50 | 3,000 | 18,000 |
Every 5 seconds | 600 | 36,000 | 2,16,000 |
Start with the per-second cap. At 5 requests a second, sending 50 requests takes at least 10 seconds, so a gap of 5 seconds can’t even be sent in time. The 600 requests a minute are also double the 300 cap, and 2,16,000 a day is over the daily limit.
A gap of 30 seconds stays under the minute cap but crosses the hourly one by 3,000. A gap of 60 seconds lands exactly on the hourly cap, with no room to spare. If your broker lets you ask for several stocks in one request, the count falls sharply.
Now see what waiting costs. Say your trigger is ₹1,350.90 and the stock rises ₹0.50 every second. With a gap of 5 seconds, you notice about 2.5 seconds late on average. That’s roughly ₹1.25 per share, or ₹125 on 100 shares. This delay is called latency, and the figure here is an illustration, not market data.
Can You Use Both Together?
Many careful traders do. Use a webhook, or your broker’s order update feed, to hear about fills and rejections quickly. Then poll slowly, once a minute or so, to check your order book (the list of your open and completed orders) and positions.
Webhooks can fail. TradingView’s own help page says webhooks may occasionally fail to reach the URL you gave. A slow poll catches whatever slipped past. Live prices still come through a WebSocket.
Pros, Cons and Risks
Polling is easy to write, even as a first Python project (Python is a beginner-friendly programming language). You set the pace, and it runs from a home laptop because you only send requests out. A missed reply gets fixed by the next one.
The cost is a high request count and a delay equal to your gap. Ask too often, and you risk errors or a block.
Webhooks use far fewer requests and bring news of fills and rejections quickly. Your program can sit idle until it’s needed. But you need a URL that’s always online, and they report events, not live prices.
These are the risks to watch:
- Blocks. Asking too often can cause errors or a pause in your access.
- Slippage. Late data can make you buy or sell away from the price you planned. That gap is called slippage.
- Duplicates. The same message can arrive twice. Give each one an ID and skip any you’ve already seen.
- Fake messages. Anyone who finds your URL can send you false data. Zerodha attaches a checksum to each postback, a code built from the order ID, the order timestamp, and your secret key. You compute it yourself and match it before trusting the message.
- Bugs. A faulty script can place repeated orders in seconds. Test with the smallest quantity.
- Rules. For API algo trading, NSE’s implementation standards under SEBI’s retail algo framework require you to give your broker a static IP, which is a fixed internet address. They also require API sessions to be logged out every day. Confirm the current rules with your broker before going live.
Tips for Beginners
- Start with 3 to 5 stocks and a gap of 30 to 60 seconds.
- Count requests before you run: stocks × (21,600 ÷ gap in seconds).
- Use a WebSocket for live prices rather than polling fast.
- Save a log of every request and reply so you can trace what went wrong.
- Plan a morning login step, since API sessions are logged out daily.
- Read your broker’s limits page before writing any code.
- Keep real money orders off until the script has run cleanly for a few weeks.
Polling vs Webhook vs WebSocket
Parameter | Polling | Webhook | WebSocket |
Who starts | Your program | The broker or service | You connect once, the broker streams |
Best for | Prices, funds, positions | Order and event alerts | Live prices and market depth (the buy and sell queue at each price) |
Delay | Up to your gap | Small | Smallest |
Requests used | High | Low | Low after connecting |
Setup | Easy | Medium | Medium to hard |
Typical user | Beginner | Someone running automation | Active intraday trader |
Common Mistakes to Avoid
- Polling every second for many stocks. You’ll hit the limits fast. Switch to a WebSocket.
- Using webhooks for live prices. They report events, not a constant stream of ticks.
- Skipping the heartbeat. A quiet WebSocket may get closed, and your data stops.
- Trusting every message. Verify it before you act.
- Relying on webhooks alone. Add a slow poll to catch lost messages.
- No alert for silence. If no price arrives for a minute, your program should tell you.
Who Should Use Which?
Polling suits beginners building a first tracker, long term investors who check portfolio value a few times a day, and swing traders who need hourly updates.
Webhooks suit anyone who wants instant order alerts, or who connects chart alerts to their trading, like the TradingView route above.
WebSockets suit intraday and options traders who need live prices.
If you trade only through the app or web platform, you don’t need any of this, since built-in charts and alerts cover it. To try coding, start at the Alice Blue developer portal and the market data documentation.
Conclusion
Polling is easy and fine for slow checks, but it eats into your broker’s limits and lags by the gap you set. Webhooks bring order news fast with few requests, though they need a receiver that stays online and can occasionally miss a message. Live prices belong on a WebSocket. For a first setup, stream prices over a WebSocket, take fill news from a webhook or order feed, and run a slow poll as backup. Try it on small quantities before real money.
Frequently asked Questions
Blog by Aliceblue News Desk
