Webhooks or Polling?

How does one system find out that something happened in another? There are two basic answers, and the choice between them affects both what the integration costs to run and how fresh the data is. One is to keep asking – polling. The other is to be told – webhooks. The difference sounds small but has big consequences, and it matters to understand what each one costs before you choose.

The two patterns

Polling means your system regularly asks another: has anything new arrived? Maybe every five minutes, maybe every hour. The system asks regardless of whether the answer is yes or no, and the vast majority of the time the answer is no.

Webhooks flip the whole relationship around. Instead of you asking, the other system notifies you on its own the moment something happens. An order is placed, a payment goes through, a contract is signed – and a small call is sent directly to you. You don’t need to ask, because you get told.

An everyday picture: polling is walking to the mailbox every five minutes to see if the mail has arrived. Webhooks is having a doorbell that rings when something is actually delivered. One costs constant unnecessary trips, the other waits until there’s a reason to react.

Polling’s hidden cost

Polling looks simple, and it’s exactly that simplicity that hides the bill. The cost is rarely a line item on an invoice – it sits in three places.

• Wasted calls. If you ask every five minutes but something only happens a couple of times a day, almost every call is wasted. You’re burdening both your system and the other one for the answer “nothing new.”
• Delay. An event isn’t discovered until the next check. With a five-minute interval, the data can be up to five minutes old before you even know about it. For anything time-sensitive, that’s too slow.
• Rate limits. Many services limit how often you’re allowed to ask. Poll too frequently to keep the data fresh, and you risk hitting the ceiling and getting temporarily cut off.

You can cut the delay by asking more often, but that increases the wasted calls and the risk of hitting the limits. You can cut the calls by asking less often, but then the data gets staler. Polling forces a compromise that webhooks avoid.

Webhooks’ weak point

Webhooks solve both the freshness problem and the wasted calls – but move the problem somewhere else. The price is called delivery uncertainty.

When you do the asking, you’re in control. If the answer doesn’t arrive, you ask again. With webhooks, you’re instead dependent on the sender reaching you, and a lot can go wrong there. Your receiver might be down exactly when the call is sent. The call can get lost along the way. It might accidentally get sent twice. Unlike polling, where you control the pace, you’re at the mercy of someone else succeeding in delivering at the right moment.

That doesn’t make webhooks unsuitable – but it means they have to be built with care to become reliable. A naively built webhook receiver that assumes every call arrives exactly once will sooner or later miss something or record it twice.

The robustness patterns that make webhooks reliable

Three patterns come up again and again when webhooks are built to hold up in the real world:

• Retries. The sender should try again if the receiver doesn’t respond, ideally with increasing intervals. That way the flow survives a brief outage on your end.
• Idempotency. The receiver has to tolerate getting the same event multiple times without doing anything twice. If it recognizes an event it has already handled, it ignores the duplicate. That’s what makes retries harmless.
• Acknowledgments. The receiver clearly confirms that an event was received. If the acknowledgment doesn’t arrive, the sender knows to try again. Without an acknowledgment, no one knows whether the call got through.

Together, they turn webhooks from something fragile into something robust: events that arrive late, twice, or after an outage still get handled correctly.

When polling is still right

Despite the costs, polling is sometimes the right choice. The clearest case is when the system you’re integrating with simply doesn’t offer webhooks – then there’s nothing to choose between. Polling also fits batch logic: if you’re only going to pull everything new once a night or once an hour anyway, the wasted calls and delay don’t matter. If volume is low and freshness doesn’t matter, polling can be both simpler and fully sufficient.

The rule of thumb: choose webhooks when they’re available and freshness matters, but build them with retries, idempotency, and acknowledgments. Settle for polling when webhooks aren’t available or when batch is enough. At Weapp we build integrations on both patterns and help you choose the right one for each flow. Check out our services or get in touch.