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.

For the complete guide, read How to Add an AI Chatbot to Your Website (5-Minute Guide).

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.

A webhook receiver should be designed for the possibility that the destination is temporarily unavailable. First confirm what the sending platform promises: whether it retries, which response codes count as success, how long it retries, and whether a delivery can be replayed from a dashboard or API. Those details vary between providers; do not assume a retry policy or invent one in your receiver. Record the provider's delivery identifier when available so the receiving application can recognize a repeated event without creating a second lead.

For a simple integration, keep the request handler short: authenticate the request using the sender's documented method, validate the expected event and payload fields, persist the event or enqueue the work, and return the response expected by the provider. Avoid doing slow CRM calls, email sends, and several downstream updates synchronously if that risks exceeding the sender's timeout. A successful HTTP response should mean the event was accepted durably enough for your design—not that every later business action completed.

A queue can separate accepting a delivery from processing it. The receiver stores a validated event in durable storage; a worker attempts the CRM or notification action and can retry transient failures with bounded backoff. After the retry limit, mark the event for manual review rather than dropping it or retrying forever. Whether a queue is warranted depends on volume and impact: a small low-risk notification may need only clear logs and a reconciliation check, while a lead pipeline with costly missed enquiries may justify durable buffering.

Make failures visible to an owner. Track accepted events, processing outcomes, age of unprocessed work, repeated failures, and the number of events that need manual review. Log enough context to investigate while redacting secrets and unnecessary personal information. Create an alert for a queue that stops draining or a destination that consistently rejects records. A green health check for the web server does not prove the CRM integration is delivering leads.

Test retries and replay in a safe environment. Simulate a temporary destination failure, a permanently invalid payload, a duplicate delivery, and a worker restart. Verify that retrying does not create duplicate CRM records and that a failed item can be diagnosed without exposing a signing secret or visitor data. Document who can replay events and how the team checks for records that were not processed. Reconciliation with the source list remains useful as a safety net, even when the real-time path is healthy.

If a provider offers a delivery history, use it alongside your own receiver logs to locate where an event stopped: was it never sent, rejected by authentication, accepted but not queued, or processed but rejected by the CRM? The exact delivery logs and replay controls are provider-specific and should be confirmed in current documentation. Keep a small runbook with the endpoint owner, the test event procedure, credentials rotation steps, and the recovery path for a prolonged outage.

The essential design principle is to make the failure path explicit. Use the provider's documented retry behavior, accept events durably when required, process downstream work safely, and alert a person when automated recovery ends. Polling can still support reconciliation, but it should not hide a webhook pipeline that silently loses work. Before relying on any chatbot webhook for leads or customer updates, verify its signature method, retry window, event identifiers, payload contract, and replay options with the vendor.

Want the full picture? Read our guide on how to add an ai chatbot to your website (5-minute guide).