How can I prevent repeated poll update notifications in Telegram bot webhook after voting?

Other Questions Telegram bot
1

I’m working with a Telegram bot that sends polls to users in private chats. Everything works fine when creating the poll, but I’m facing an issue after someone votes.

Once a user votes on the poll, my webhook keeps receiving the same poll update message repeatedly (about every minute). The webhook payload looks something like this:

{
  "update_id": 299847362,
  "poll": {
    "id": "4185274961387205421",
    "question": "What's your choice?",
    "options": [
      {"text": "option_a", "voter_count": 1},
      {"text": "option_b", "voter_count": 0},
      {"text": "option_c", "voter_count": 0}
    ],
    "total_voter_count": 1,
    "is_closed": false,
    "is_anonymous": true,
    "type": "regular",
    "allows_multiple_answers": false
  }
}

I tried removing the poll message but the updates continue coming. Since this is a private conversation with the bot, I only need to get the voting result once and then stop the poll completely. Is there a way to acknowledge these updates or close the poll programmatically to stop the repeated notifications?

2

Your webhook isn’t properly acknowledging updates to Telegram’s servers. Just tracking update IDs or returning 200 codes won’t fix this - you need proper flow control.

I’ve dealt with tons of these webhook loops in production. Telegram batches poll updates and expects specific acknowledgment patterns that most basic webhook handlers completely miss.

What actually works: set up an automation flow that processes the webhook, immediately calls stopPoll, then sends the right response headers back to Telegram in the correct sequence. Manual coding screws this up because timing between API calls is crucial.

I moved all our bot workflows to Latenode since it handles webhook acknowledgment automatically and lets you build poll management logic visually. You can see exactly when each API call happens and debug if things break.

The automation tracks poll states, removes duplicate updates, calls stopPoll at the right time, and sends clean responses back to Telegram. No more repeated notifications and way less code to maintain.

3

You’re getting repeated updates because Telegram keeps broadcasting poll changes until you close it. Just call stopPoll immediately after processing the first vote - that’ll stop the spam.

Here’s what works: track poll IDs in memory or a simple cache. When an update comes in, check if you’ve seen that poll ID before. If yes, ignore it and send a 200 back to Telegram.

For the polls you haven’t processed yet, grab whatever data you need, then immediately hit the stopPoll API. Speed matters here - you want to close it before Telegram’s next broadcast cycle kicks in.

I’ve used this approach in my own bot and it works great. No need for external services or fancy database setups.

4

Had this same problem for months until I completely changed my approach.

Telegram keeps pushing poll state changes and there’s no clean way to acknowledge them. You can use stopPoll but timing is everything.

What fixed it for me: I moved my bot logic to Latenode and built a workflow that tracks processed poll updates. You create a simple database storing poll IDs you’ve handled, then filter duplicates before they reach your main code.

Best part - you can auto-call stopPoll right after getting the first vote, then clean up your database. Takes 10 minutes to build and handles all API calls automatically.

No more duplicates, no messy webhook code. Just clean poll management that works.

5

check ur webhook response code first - if u ain’t returning a 200 status, telegram keeps retrying the same update. also make sure ur server processes requests quickly. slow responses trigger more retransmissions. i had the same issue and it was just my server taking too long to respond.

6

The duplicate poll updates happen because Telegram’s webhook doesn’t distinguish between new votes and retransmissions of the same poll state. You need to handle idempotency in your app. I fixed this by storing each update_id from the webhook payload in a database or cache with a TTL. Before processing any poll update, check if you’ve already handled that update_id. If yes, just return HTTP 200 and skip everything else. Here’s the key: update_id is unique for each webhook delivery, so tracking these prevents duplicate processing even when the poll data looks identical. After you collect your vote data, call stopPoll and you’re done - no more repetitive notifications. This beats just tracking poll IDs because you might actually want multiple updates from the same poll as different users vote.