Webhooks or periodic synchronisation: which integration fits your process?

An order that only shows up in the stock system an hour later. A CRM that says something different from the customer portal. An invoice that gets created twice. In most cases there is nothing wrong with the applications themselves, but with the way they exchange data.

The question of webhooks or periodic synchronisation is usually framed as a technical one. It barely is. What matters is how much delay your process can take, what happens when a connection is down for half an hour, and who notices when the data is wrong.

As long as orders, customer records and statuses flow through neatly, nobody thinks about the integration. That is the point. But the moment two systems show a different version of the truth, somebody on the floor picks up the manual work. And the argument that comes with it.

The practical difference in two paragraphs

A webhook pushes. The moment something happens (a new order, a changed subscription, a closed ticket) the source system calls an endpoint you have given it. The receiving system processes the message and that is that.

Periodic synchronisation pulls. Your system asks the other system every five minutes, every hour or every night what has changed, fetches it and processes it. Polling, in jargon.

Push against pull, put simply. But that single choice decides how quickly processes react, how much traffic goes over the wire, how you catch errors and how much maintenance you spend on it every month.

When webhooks are the right call

Webhooks suit changes that have immediate consequences. A web shop that has to update availability in the basket after a sale. An access platform that has to settle a payment before the visitor is standing at the door. A customer portal that should show a confirmation straight away.

The gain is speed: you are not waiting for the next round. That matters most for processes the customer can see, or where an employee would otherwise be sitting on their hands.

There is a condition attached. The receiving system has to be there at the moment the message arrives, and that is not always the case. Maintenance is running, the server is too busy, or the application is temporarily unreachable. So an integration built on webhooks needs sender verification, validation of the payload, logging per message, and a provider that delivers again when the first attempt fails.

Count on duplicate messages too. If your acknowledgement does not come back, the provider sends the same event again. Your processing has to absorb that: the same order update arriving twice must not produce two invoices, two stock movements or two welcome emails. A reference of your own per event, plus a check on whether you have seen it before, is usually enough in practice.

Speed is not a goal in itself

Pick webhooks when a few minutes of delay is already noticeable, when users are waiting on a result, or when the events are few but significant. Payments, new leads, changed bookings, shipments, status updates.

Not every process gets better with real time. If a status is only looked at internally and can be refreshed at the start of the working day, immediate processing mainly adds requirements around availability and error handling that nobody will ever notice.

When periodic synchronisation works better

If the data does not have to be available instantly, a scheduled synchronisation is often the calmer choice. Think of product information, reporting, historical data or the daily export to the finance system.

The advantage is control. You decide when the integration runs, how many records go through at once and how hard you load both systems. That counts when an external API has hard limits, when datasets are large, or when the source system is only reliably available at fixed moments.

Take an ERP that processes mutations in a nightly batch. Dozens of webhooks spread across the day buy you very little there, because nothing happens administratively until that batch runs anyway. A synchronisation that starts just after the night run fits the way the organisation actually works.

Sometimes there is no choice either. Plenty of older systems and business packages only offer an API you can read from. Polling is not a compromise then, it is simply how that software was built.

The trap: synchronising too often

Running every minute feels safe. It is not automatically better. If there are hardly any changes, you keep asking for more or less the same data. You burn through API limits, run into costs where billing is based on usage, and fill your logs with lines nobody can find anything in later.

So set the interval from the process, not from the technology. Can a customer wait five minutes for an update? Then it does not need to run every minute. Is a supplier catalogue delivered once a day? Then a nightly job is enough. The best frequency is not the shortest one, but the one that matches the risk, the volume and what people expect.

In practice it is often both

The choice is rarely either/or. In integrations that last for years, webhooks and periodic synchronisation do different jobs: the webhook handles the fast processing, the scheduled run checks afterwards whether it all adds up.

Take an order integration. The web shop sends a new order straight through to the fulfilment system. Overnight, a synchronisation compares the orders and statuses on both sides. A missed message, a failed process or a manual correction surfaces within a day instead of at the monthly close.

With business critical data that is exactly where the difference lies. The webhook gives you speed, the reconciliation run gives you recovery. Without that second layer, two systems can follow their own version of reality for weeks without anyone spotting it.

Reliability lives in the groundwork

Webhooks, polling or a mix of both: in the end it is everything around the integration that decides whether it stays on its feet. An integration without error handling works beautifully until the first network glitch, the first expired token or the first field that suddenly comes through empty.

These are the parts we come back to most often in practice:

• Stable identification of records. Both systems need to know which customer, order or change belongs to which record. Work with external IDs that do not change, not with names or email addresses.
• Logging a human can read. Record what came in, what was processed, what was rejected and what was retried. A bare "error 500" on a busy Monday morning gets nobody anywhere.
• Recovery after an outage. Messages must be replayable or retrievable. Agree how far back you can go as well, because seven days of events is a very different thing from two hours.
• Verification and limited rights. Check who is sending a webhook, use secure authentication for your APIs, and give the integration no more permissions than it needs.
• Monitoring with a name attached. An alert is only useful once somebody knows it is theirs. Write down who responds, and within what time.

That last point is the one most often skipped. Technology can happily report that a synchronisation failed, but without an owner that alert stays a line in a dashboard nobody is watching.

Start with the process, not with the API

"Does this package support webhooks?" is the wrong first question. The better one: what goes wrong operationally if this change is processed ten minutes, an hour or a day later?

Map out, per data flow, what is being exchanged, which system is the source and what the delay costs. A price change, a payment status and an internal note do not carry the same urgency. Write down which system leads, too. If CRM and ERP are both allowed to edit customer data without rules about who wins, no synchronisation method is going to resolve that conflict for you.

Go through the exceptions before anyone writes code. What if an order is cancelled while the shipment has already been registered? What if the same customer record is edited in both systems at once? What if the external API goes quiet for an hour? Questions like those decide whether you end up with an integration that works in a demo, or one you are willing to run your operation on.

Keep the choice manageable

An integration is not finished when it works, but when somebody else can still adjust it a year from now. So document which systems talk to each other, which events or intervals are in play, where the logs live and how recovery works. That takes out the dependency on a single developer or supplier.

At LJPc we therefore look further than whether something is technically possible. Development, hosting, monitoring and a phone number that gets answered when something breaks all belong together. An integration between systems should take work away, not add a new thing to keep an eye on.

Pick webhooks when immediate action is needed. Pick periodic synchronisation when control, predictability or a limited load weigh heavier. And when it comes to data your operation leans on, combine the fast route with a fixed reconciliation run. A good integration does not ask your team to check it daily, but it does let you put things right within a day once reality starts to drift.