Why your CRM webhook will fail, and what to do about it
A webhook is a single point of failure that fails silently. Two patterns — idempotency and a scheduled poll — turn it into something you can rely on.
5 min read
The four ways it fails
None of these are exotic. All four happen in ordinary accounts within the first month.
- 01The workflow is saved but never published, so nothing fires at all.
- 02The same event is delivered several times, and every delivery sends another email.
- 03The payload for one event type is stripped down, so a cancellation arrives without the name or calendar.
- 04The endpoint is briefly unreachable and the retry window expires.
Idempotency first
Decide what makes an event unique — usually the record identifier plus a normalised status plus the start time — and enforce it at the database with a unique constraint. Claim the event by inserting that key; if the insert fails, another delivery already handled it and this one does nothing.
Do not implement this with a check-then-write in application code. Two deliveries arriving in the same second will both pass the check.
Never let a thin payload overwrite good data
When an event arrives with fewer fields than you already hold, merge rather than replace: keep every value you have and fill only what's genuinely new. Otherwise a cancellation payload can wipe the name, email and calendar off a record you'd already enriched.
The poll behind the webhook
Every ten minutes, ask the source system directly for recent and upcoming records and reconcile. Run it through exactly the same ingestion code as the webhook so there's one behaviour to reason about, and tag each row with which source found it.
Backfilled records from the past should be recorded silently — no emails for meetings that already happened.
Make the health visible
Put one line where you'll actually see it: when the webhook last delivered, when the poll last ran, and how many records each has picked up. Silent integrations are how you find out three weeks later.