One Telegram Order, Two CRM Leads: Find the Replay Before Patching the Bot
Use update_id, response history and the CRM side-effect key to tell a Telegram webhook retry from a genuinely separate order before quoting a duplicate-record repair.
Signals to watch
- Two CRM objects can be tied to one Telegram update_id rather than merely similar message text
- The first handler attempt committed the side effect before an unsuccessful HTTP response
- The repair has one durable idempotency key and a repeatable one-update-one-effect test
When one Telegram order creates two CRM (customer relationship management) leads, prove that the same update_id produced both side effects before changing deduplication rules. Then make the handler idempotent: record the delivery identity and accepted business action durably, so a retry can return success without creating the lead again. Similar text or two nearby timestamps are not enough.
This is a commercial qualification problem for a sales engineer at a Telegram-to-CRM integration provider watching authorised bot-support, ecommerce-automation and CRM-operations groups. A thread with the same Update, two CRM object IDs and a repeatable response history can support paid repair work. A post that only says “duplicates again” may describe two customer messages, a CRM workflow rule, a manual import or an application retry unrelated to Telegram.
Here is an illustrative composite, not a customer incident or measured result:
same tg order made 2 leads again. first call timed out, retry got 200. need fix before next launch
Known: someone reports two leads, a timeout, a later HTTP 200 and a need for help. Unknown: whether the update_id matched, which component timed out, whether the first attempt committed, which CRM keys were used, how many records were affected, when the launch is, who owns the system and whether follow-up is permitted.
Idempotency means the retry changes nothing the second time
An operation is idempotent when repeating the same logical request does not create another intended business effect. For this repair, the practical promise is narrow: processing the same Telegram Update twice should not create a second CRM lead.
The Telegram Bot API (application programming interface) gives the delivery a useful identity. Its update_id is unique in the bot’s update stream, and Telegram explicitly says it can be used to ignore repeated webhook updates. That makes it a strong delivery-level key. It is not necessarily the final business key: an edited order, a follow-up message or a deliberate second request may require separate application rules.
The safest qualification question is therefore two-part:
- Did the two handler attempts carry the same
update_id? - Did both attempts create the same intended business object?
If the first answer is no, the problem is not a simple delivery replay. If the second answer is unknown, the team has not connected delivery evidence to the reported CRM symptom.
The duplicate usually appears between commit and acknowledgement
Telegram’s setWebhook documentation says it sends an HTTPS POST containing a JSON-serialized Update. If the response has an unsuccessful status—documented as something other than 2XY—Telegram repeats the request and gives up after a reasonable number of attempts. Telegram does not publish a fixed retry interval or count there, so do not invent one in a quote.
A revealing failure sequence looks like this:
| Boundary | First attempt | Retried attempt |
|---|---|---|
| Delivery | update_id 8412 arrives | update_id 8412 arrives again |
| Handler | CRM create is sent | CRM create is sent again |
| Business side effect | Lead L-301 is committed | Lead L-302 is committed |
| HTTP response | Endpoint times out or returns non-2XY | Endpoint returns 200 |
This table is an explanatory model, not an observed customer log. It shows why checking only the final HTTP 200 misses the actual boundary: the first attempt may have completed the irreversible business action before the sender knew it had succeeded.
Repair the transaction boundary, not the screenshot
A robust implementation needs one durable decision around the repeated delivery. The exact design depends on the stack, but the evidence should answer the same questions:
- Where is
update_idstored, and is the uniqueness rule enforced under concurrent requests? - Does the handler mark the Update processed before or after the CRM accepts the operation?
- What happens if the process stops between the CRM commit and the local processed marker?
- Can the CRM accept an idempotency key or an external reference that is stable across retries?
- Does the endpoint acknowledge only after durable acceptance, whether that means a committed transaction or a durable queue write?
“Check whether the lead already exists” is not a complete repair when two attempts can run at once or when matching relies on mutable fields such as name or message text. The implementation needs a key and a concurrency-safe write rule, not a longer delay.
The webhook secret_token solves a different problem. Telegram can send it in the X-Telegram-Bot-Api-Secret-Token header so the endpoint can check the configured value. That supports request-origin verification. It does not prevent the same accepted Update from being processed twice.
Reproduce one replay without touching real customer records
Before quoting, ask the authorised engineering owner for a redacted trace or test fixture. It should include the Update identity, two handler-attempt identifiers, response outcomes and the two claimed CRM object IDs. Bot tokens, unredacted customer messages and production credentials do not belong in a group thread.
The acceptance test should run in an approved environment:
- submit the same fixture more than once, including concurrently if the production path can overlap;
- observe one accepted business side effect;
- observe a durable record explaining why later attempts were treated as duplicates;
- submit a genuinely different Update and confirm that it is not discarded;
- simulate the failure boundary that originally caused the unsuccessful response.
This test distinguishes an idempotency repair from a rule that merely suppresses everything after the first event.
When the thread is ready for a repair quote
The request becomes technically specific when one update_id links two attempts and two CRM object IDs, the first commit/acknowledgement boundary is known, an owner can provide safe access and “one Update, one side effect” is observable. Until then, a sales engineer can offer discovery or a paid diagnostic, but should not promise the root cause.
TOP Prospect can preserve authorised fragments, repeated wording, source times and unknowns in one review candidate and rank the reproducible request ahead of generic integration complaints. It cannot inspect logs, certify the update identity, delete CRM records or contact the requester. Its current production matching-target interface saves configurations but does not automatically create new candidates. The Telegram-to-CRM workflow article covers source and handoff fields; the update delivery map separates the four receipts; the status-page evidence article helps keep an operational report separate from a sales inference. Available product access is listed on pricing.
Key facts
- Telegram repeats a webhook request after an unsuccessful HTTP response; the official page does not promise a fixed retry schedule.
update_ididentifies the Bot API delivery and is useful for ignoring repeated updates.- Two similar messages do not prove one repeated Update.
- A secret-token header supports origin checking, not idempotent business processing.
- A correct repair preserves genuinely different Updates while making repeated handling of the same logical event harmless.
- Identity, authority, system access, affected scope and contact permission still require human verification.
FAQ
Why does Telegram retry a webhook?
Telegram documents that it repeats webhook requests after an unsuccessful HTTP response and stops after a reasonable number of attempts.
Which field should identify the Telegram delivery?
Use update_id to identify the Bot API Update. A separate business key may still be needed for the intended CRM object.
Does a webhook secret token prevent duplicate CRM records?
No. It helps the endpoint check the documented request header. It does not make the handler or CRM side effect idempotent.
What proves the duplicate repair works?
Submitting the same authorised test Update more than once produces one accepted business side effect and a recorded duplicate decision without losing a genuinely different Update.
Editorial review completed 26 August 2026 against Telegram’s setWebhook, Update and getWebhookInfo documentation.
Frequently asked questions
Why does Telegram retry a webhook?
Telegram documents that it repeats webhook requests after an unsuccessful HTTP response and stops after a reasonable number of attempts.
Which field should identify the Telegram delivery?
Use update_id to identify the Bot API Update. A separate business key may still be needed for the intended CRM object.
Does a webhook secret token prevent duplicate CRM records?
No. It helps the endpoint check the documented request header. It does not make the handler or CRM side effect idempotent.
What proves the duplicate repair works?
Submitting the same authorised test Update more than once produces one accepted business side effect and a recorded duplicate decision without losing a genuinely different Update.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.