Why a lead goes missing and what stops it
4 min read
When a lead goes missing, the culprit is usually not “the internet” but one specific step. Let us go through which step it is and what closes it.
Where the lead comes from
The moment someone fills in a Facebook or Instagram form and taps the submit button, Meta sends Yuboraman a signed webhook. The lead does not wait in a queue — it enters the system the instant it is submitted.
The signature is not there for show: every request arrives with Meta's signature and that signature is checked. A request whose signature does not match is not accepted as a lead, so an outsider cannot push a fake lead into your integration.
When this step works, the lead is in the system the moment the form is submitted. Trouble usually starts at the next step — delivering the lead to your destination.
When delivery fails: the retry ladder
The destination is not always ready: the Telegram bot may be blocked, the CRM may not answer, the sheet may not open for a while. In that case the lead is not thrown away — the delivery is retried.
The pause between attempts grows each time but never goes past five minutes. If the destination itself says “wait this long” (the Retry-After header in its response), the system honours exactly that interval instead of hammering the service and running into its limit.
If all three attempts come up empty, the lead is not forgotten: an hourly sweep collects everything left undelivered over the last twelve hours and sends it again. Even if the CRM was down for half an hour, once it is back the leads reach their place.
- Three retries
- The wait grows with every attempt, five minutes at most
- The Retry-After header sent by the destination is honoured
- Every hour, whatever went undelivered in the last 12 hours is retried
What happens if the webhook misses one
A webhook is reliable but not perfect: a message can get stuck in the network or on Meta's side. So there is a backup mechanism underneath it.
Four times a day the system asks Meta itself for the leads of the last twenty-four hours, finds the ones that never arrived by webhook and puts them into processing. Even if one message is lost, the lead is caught by the next sweep at the latest.
This backup is there for completeness, not for speed. Normally the lead arrives by webhook straight away; the sweep only closes the gaps.
Why one lead sometimes arrives twice
Two paths can lead to the same lead — the webhook and the backup sweep. So there is duplicate control: every lead is remembered by the identifier of its source message, and if that identifier turns up again the lead is not sent a second time.
How far back it looks depends on the source: thirty days for Facebook leads, seven days for site webhooks. The control is kept separately per integration and is not configurable. What matters: it works by the source message, not by the phone number — if one person fills in two different forms, that is two separate leads.
Even so, delivery does not guarantee “exactly once”. When the destination's answer stays unclear — the request went out, no response came back — the system tries again, and a duplicate can appear. The trade-off is deliberate: a repeated lead costs less than a lost one.
The honest limit: twelve hours
Automatic retries do not run forever. If the destination has not accepted the lead within twelve hours, the system stops trying and the lead stays in an undelivered state.
What comes after that is a person's job: you find the lead in the panel and press resend yourself. That is deliberate: a destination that has not answered for twelve hours usually has broken settings or is switched off, and endless retries only fill up the queue.
In practice that means: if you notice a destination has been silent for a while, check it the same day. After twelve hours the lead will not go by itself.