@Quadri_Abdulsalam1 when it dupes, check the Executions list, is the workflow running multiple times per incoming message, or just once? multiple = Telegram resending the update (a retry), once = a loop or multi-item node firing your send repeatedly. lmk which, or share the workflow.
Good point from @kall about retries. To add to the root cause: Telegram automatically retries a webhook call if your n8n workflow doesn’t respond with a 200 status within a few seconds. If your workflow has many nodes (AI call, multiple HTTP requests) before the response goes back to Telegram, that’s often enough to trigger a retry.
Practical fix alongside the update ID check: Split the workflow into two parts. A lean first part that responds immediately with 200 OK (right after the Telegram trigger), and a second part that handles the actual processing (generate AI response, send message) asynchronously—for example via a sub-workflow called through “Execute Workflow” without waiting. This prevents the retry problem at its root, not just the symptoms.
Hey @Quadri_Abdulsalam1, great points above. To make the update_id deduplication concrete, here’s a quick Code node you can drop right after the Telegram Trigger:
const updateId = $input.first().json.update_id.toString();
const seen = $getWorkflowStaticData(‘global’);
if (seen[updateId]) {
return []; // already processed, stop here
}
seen[updateId] = true;
return $input.all();
This uses n8n’s built-in static workflow data to remember which update_id values have already been processed, no external DB needed. Combine this with Rene’s suggestion of splitting into a fast-response sub-workflow, and duplicate sends should stop entirely.