Webhooks instead of polling: real-time integration

Two systems that need to work together have two options. Either one asks regularly — “anything new?” — or the other speaks up when there is something new. The first is polling, the second a webhook. The difference sounds technical and decides, in practice, whether an integration runs quietly or constantly demands attention.

Why asking is the worse half

With polling your system asks at fixed intervals. Every five minutes, every hour, every night. That has three unpleasant properties.

It’s almost always for nothing: of 288 calls a day, maybe twelve return something. The other 276 burn calls that count against your limit.

It’s still too slow: asking every five minutes means learning things two and a half minutes late on average. For an order heading to the warehouse that’s often fine. For a payment that releases a delivery, it isn’t.

And it’s fragile in the details: you have to remember how far you’ve already read. If that marker slips — a run aborted, a time zone calculated differently — data goes missing and nobody notices.

What a webhook actually is

A webhook is an address you register. When something happens — a document is created, an invoice changes status — the software sends a message to that address. No asking, no marker, no empty rounds.

For that to hold up in production, three things are needed. Ask about them before buying.

1. A signature, or you’ll believe anyone

Your webhook address is publicly reachable. Without verification, anyone who knows it can send an invented message — and your system creates an invented order.

So every delivery is signed: the sender computes a checksum from the payload and a shared secret, and sends it along. Your system recomputes it. If it doesn’t match, the message is dropped.

One detail that’s often missing: the timestamp must be part of the signed payload. Otherwise someone can capture a genuine message and replay it later — the signature still matches. With the timestamp signed, the replay stands out.

2. Retries that spread out

Your server will be unreachable at some point. A restart, a certificate, a network — it happens. The question is what the sender does then.

Retrying immediately doesn’t help: something that’s restarting isn’t there a second later either. Growing intervals are sensible — immediately, after 30 seconds, after 5 minutes, after half an hour, after two hours. That bridges the short restart as well as the longer outage.

And: an error in your request (wrong format, revoked key) is not retried. Sending the same thing five times doesn’t fix a format — it only buries the real error.

3. An end, when nobody is listening

If an address stops answering permanently, the sender has to give up at some point and say so. Otherwise deliveries vanish into nothing until someone notices — usually weeks later, when data is missing.

At Blina Desk an endpoint is suspended after five exhausted deliveries in a row and has to be re-enabled by hand. “Exhausted” means every retry is spent. A single hiccup suspends nothing.

What your receiver has to do

The other side has duties too, and two of them are regularly forgotten.

Answer fast. Accept the message, acknowledge it, and then process it. Anyone who computes first and answers second runs into timeouts and gets the same message again.

Tolerate duplicates. Which is exactly why the same message can arrive twice. Your receiver has to cope without creating the order twice: every delivery carries an id, and you’ve either seen it before or you haven’t.

The rule of thumb

Use webhooks for anything that should happen promptly, and keep a nightly reconciliation as a net underneath. The webhook keeps the systems in step; the reconciliation catches whatever got stuck during a night with a bad connection. Together they make an integration you stop thinking about — and with integrations, that’s the highest praise there is.