Building

Telegram webhooks vs long polling: which to use and why

By the Botable team

A Telegram bot receives updates one of two ways: long polling, where it repeatedly asks Telegram for new messages, or a webhook, where Telegram posts them to your HTTPS URL. You can use one or the other, never both — setting a webhook disables polling.

The short version

Telegram offers two delivery mechanisms for bot updates and they are mutually exclusive. Long polling has the bot call getUpdates in a loop, holding each request open until something arrives; it needs no public address, no domain and no certificate, which makes it the right choice for local development and small bots. Webhooks invert the direction: you register an HTTPS URL and Telegram posts each update to it as it happens. That scales better, costs nothing while idle, and fits serverless hosting, at the price of requiring a publicly reachable endpoint with a valid certificate. The mutual exclusion is where bots break: registering a webhook silently disables getUpdates, so a polling bot stops receiving anything the moment a second deployment or a forgotten test script sets one. Nothing errors — the bot simply goes quiet.

Step by step

When is long polling the right choice?

Local development, always — you cannot receive a webhook on a laptop without a tunnel. Also for low-traffic bots on a machine that is already running continuously, where the simplicity of no domain and no certificate outweighs the idle cost of the polling loop.

When are webhooks the right choice?

Production, in most cases. Delivery is immediate rather than up to one poll interval late, there is no cost while nothing is happening, and it works on platforms that only run code in response to a request. Any bot expected to scale should be on a webhook.

What does a webhook require?

A publicly reachable HTTPS URL with a valid certificate — self-signed is possible but awkward. Add a secret token to the registration so you can verify that incoming requests are genuinely from Telegram, because the endpoint is public and anything can post to it.

How do you switch between them?

To move to a webhook, register it. To move back to polling, delete the webhook first — otherwise getUpdates keeps returning nothing and the bot looks broken. Deleting also lets you discard the queue of updates that accumulated while things were misconfigured.

What catches people out

  • Setting a webhook disables polling silently, with no error anywhere
  • Two instances polling the same token split the updates between them, so each sees about half
  • A webhook endpoint is public — verify the secret token, or anyone can post fake updates to it

Questions

Which is faster?

Webhooks, by the length of your poll interval. In practice both feel instant to a user for a conversational bot; the real differences are cost while idle and how well each fits your hosting.

Can I test a webhook locally?

Yes, with a tunnelling tool that gives your machine a temporary public HTTPS URL. Remember to re-register the webhook when the tunnel URL changes, which it does on most free tiers each restart.

Want a bot that does this?

Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you — the token, the webhook, the storage, the hosting.

Build a bot

Keep reading

Bots that use this

All twenty-five guides