Webhooks vs. polling: how to actually wire up chatbot events

Polling an API on a timer for new conversations or leads means you're always trading latency against request volume — poll less often and you're slow to react, poll more often and you're burning rate-limit budget on mostly-empty responses. It's a pattern that made sense when webhooks weren't universally available, and it persists mostly out of habit: a cron job that hits an endpoint every five minutes, checks if anything new showed up, and does nothing on the vast majority of runs.

Webhooks flip the model: your endpoint sits idle until an event actually happens, then receives a payload the moment it does. For a lead-capture flow, that's the difference between a Slack notification seconds after a visitor submits their email and one that shows up on the next scheduled sync — which, depending on your polling interval, could be minutes later, well after the visitor has closed the tab and moved on. For time-sensitive events like a new lead or a conversation flagged for follow-up, that delay is the whole difference between a fast response and a missed one.

Setting one up is usually a five-minute task: register an endpoint URL, choose which events you want — lead.created, chat.completed, subscription.updated, and a handful of others — and save the signing secret shown at creation time. That secret is shown exactly once; if you lose it, you'll need to rotate it rather than retrieve it, so store it in whatever secrets manager your team already uses rather than a chat message or a sticky note.

Verification is the part worth not skipping. Every delivery includes a signature header computed from the payload and your signing secret — checking it on your receiving end confirms the request actually came from the platform and wasn't spoofed by something watching your public endpoint URL. Skipping verification because "it's probably fine" is the kind of shortcut that's invisible right up until it isn't; it costs a few lines of code to check an HMAC and a real amount of risk to skip it.

The one thing polling still does better is resilience against a flaky receiving endpoint. If your webhook URL is down when an event fires, that delivery needs retry logic on the sending side — which a reasonable webhook system handles for you with backoff — and a way to reconcile via the delivery log after the fact, in case a delivery genuinely never lands. Treat the delivery log as your safety net, not your primary integration path: check it when something looks like it's missing, not as a substitute for acting on webhooks in real time.

In practice, most integrations are best served by webhooks for real-time action and an occasional API read for reconciliation — not one or the other exclusively. A Slack notification on lead.created gets someone's attention immediately; a once-a-day pull of the full leads list catches anything a webhook delivery genuinely missed, whether from an outage on your end or a delivery that failed all its retries. Neither replaces the other; together they cover both the common case and the edge case.

The broader lesson generalizes past chatbots: any system emitting events that matter to you in near-real-time is a candidate for webhooks over polling, and the switch is almost always a net simplification once it's wired up, not an added complexity. You write the receiving handler once, and from then on you're reacting to what actually happened instead of asking on a timer whether anything did.

Want the full picture? Read our guide on how to add an ai chatbot to your website in minutes.