What to choose
Polling vs webhook for a Telegram bot: which to choose
In short
For most small Telegram bots polling is simpler: the bot asks Telegram for new messages itself and needs neither a public address nor HTTPS. A webhook works the other way round: Telegram pushes messages to your HTTPS address, so the bot becomes a small web app. Response speed is practically the same either way for a typical bot. Choose a webhook if the bot already lives inside a website or you specifically need a web endpoint, and start with polling otherwise.
- With polling the bot calls getUpdates and waits for new messages; with a webhook Telegram sends each message to the bot's address as a POST request.
- Webhooks work only over HTTPS and only on ports 443, 80, 88 or 8443.
- While a webhook is set, getUpdates does not work and Telegram replies with a 409 Conflict error.
- If the bot is unreachable, Telegram keeps incoming updates for up to 24 hours with either method.
- Polling is easier to debug: the bot runs on your own computer without a public address or certificate.
A first bot is almost always written with polling: the code ends with a line like start_polling or run_polling, and the bot works. Then articles and chats start mentioning webhooks as the proper, production way, and you wonder whether it is time to rewrite. The answer does not depend on fashion but on where the bot lives and how you prefer to debug it.
With polling the bot keeps asking Telegram whether there are new messages and waits for the answer. With a webhook you tell Telegram the bot’s address once, and from then on Telegram sends every new message there itself. Below is how the two differ in practice and how to choose.
| Criterion | Polling (getUpdates) | Webhook (setWebhook) |
|---|---|---|
| Who starts the conversation | the bot asks Telegram | Telegram comes to the bot |
| Public address and HTTPS needed | no, outbound internet access is enough | yes, an HTTPS address on port 443, 80, 88 or 8443 |
| Response speed | near-instant thanks to long polling | near-instant |
| Load when there are no messages | the process runs all the time and holds a connection | the app simply waits for incoming requests |
| Setup effort | one line to start in the library | a web server in your code plus a setWebhook call |
| If the bot is down or restarting | picks up queued updates after it starts | Telegram retries delivery, updates are kept up to 24 hours |
| Debugging on your computer | just run the script | needs a public address, such as a tunnel |
| Two copies of the bot with one token | they knock each other out with a 409 error | updates go to the single address from setWebhook |
Start with polling if the bot is small#
For a bot with commands, buttons and a few hundred users polling is entirely sufficient. It needs no public address, no certificate and no web server in your code: the bot starts with one line and behaves the same on your computer and on a server. There is no lag either: libraries use long polling, where Telegram keeps the request open and answers as soon as a message arrives. The only requirement is that the bot process runs continuously.
Choose a webhook if the bot lives inside a web app#
A webhook is convenient when you already have a website or API, say on FastAPI, Django or Express, and the bot is part of it. Telegram's messages then arrive as ordinary requests to one of the app's routes, and no separate bot process is needed. Webhooks are also chosen for very high message volumes or when the platform is built around web apps. A webhook needs an HTTPS address on one of the ports Telegram accepts.
Do not enable both at once#
While a webhook is set, Telegram will not hand out updates through getUpdates and replies with a 409 Conflict error. So when moving from a webhook back to polling, remove the webhook with deleteWebhook, and when moving to a webhook, take the polling call out of your code. getWebhookInfo shows the current state: the address and the last delivery error, if there was one.
Plan how you will debug#
With polling you can run a test bot right on your computer: no addresses, no certificates. Local debugging is harder with a webhook, because Telegram has to reach your machine, so you need a tunnel with a public address or a test copy on a server. A practical rule for both: the real bot lives on a server, and for experiments you create a separate test bot in BotFather with its own token.
Understand how the choice affects hosting#
A polling bot is a background process without an address: it needs a place where it runs around the clock and is restarted after a failure. A webhook bot is a web app: it needs a public HTTPS link and has to answer incoming requests quickly. In neither case do you need to open ports on your home router or buy a certificate, as long as your host gives you an HTTPS address.
Polling is not an outdated method, it is the simplest one: for most small bots it is more than enough, and there is no reason to switch without a need. Choose a webhook when the bot is built into a web app or you need a web endpoint specifically. Both work on Netrun: a polling bot runs as a background process, and a webhook bot needs an HTTPS link — if the platform did not give one, press “I need a link” on the project page and pass the address to setWebhook. On the free plan a bot runs for 3 hours, so for a bot that must always reply right away, choose Pro with either method. Try Netrun.
Common questions
Which replies faster, polling or a webhook?
For a typical bot there is practically no difference. Libraries use long polling: the request to Telegram stays open and returns as soon as a message arrives. A webhook only wins on speed with a very heavy message flow.
Do I need my own domain for a webhook?
No, any public HTTPS address on port 443, 80, 88 or 8443 will do. If your host gives you an HTTPS link, you do not need to buy a domain or a certificate. You can attach your own domain later if you need it for other reasons.
Will messages be lost while the bot is off?
Usually not: Telegram keeps incoming updates for up to 24 hours with either method. A polling bot picks them up after it starts, and Telegram retries delivery to a webhook bot. If the bot was down for more than a day, the older messages are gone.
Can I switch from polling to a webhook without rewriting the bot?
Your reply logic stays the same, only the startup changes. aiogram, python-telegram-bot and Telegraf all have a built-in webhook mode: instead of starting polling, the bot brings up a small web server and registers its address with setWebhook. Remember that the app has to listen on the port your host gives it.
Why does my bot get a 409 error after switching to polling?
Most likely a webhook is still set for the bot. As long as it exists, Telegram will not hand out updates through getUpdates. Delete it with deleteWebhook or enable the library option that drops it on startup.
Can I host a Telegram bot?
Yes. Upload the bot code and provide the token from BotFather (Telegram itself gives it to you when you create the bot) — Netrun starts the bot, and no VPS or manual setup is needed. On the free plan the bot runs for 3 hours so you can check everything; to keep it running around the clock, switch to the Pro plan.
What happens to my bot after 3 hours on the free plan?
The bot switches off, but your code, settings and secrets stay where they are — we delete nothing. Shortly before it switches off we send you a warning. The three hours only count while the bot is actually running: while it is stopped, still building or crashed with an error, the clock stands still — you can fix the code and start it again without losing time. Switch to the Pro plan, and the bot starts again from the same place and runs around the clock. A new bot uploaded after that is built too, but it will not start: free time is counted per account, not per project.
Why does my website sometimes sleep?
On the free plan, websites sleep after being idle and wake up in a couple of seconds on the first request. On the Pro plan your project runs without sleeping.