The simplest answer to "what is a webhook" is this: when something happens in one system, that system notifies another one on its own, saying "this just happened." A payment was received, an order was canceled, a package was delivered; the moment the event happens, a short message is sent to the other side. The other side receives the message and does what is needed.
The alternative is periodic polling. With this method, one system asks the other at set intervals, "Is there anything new?" Every five minutes, every hour, every night. The answer is usually "no," but the asking still happens.
An everyday analogy: polling is checking the door every hour to see whether your package has arrived. A webhook is the courier ringing the doorbell.
The difference between a webhook and periodic polling
| Topic | Webhook | Periodic polling |
|---|---|---|
| Speed | Notification arrives the moment the event happens | Delay of up to one polling interval |
| System load | A message is sent only when an event occurs | Requests keep coming even when nothing happens |
| Setup | The other side must support webhooks | Works with almost any system |
| Risk of missing events | If the message does not arrive, the event may be missed | Caught at the next poll |
| Control | The sender decides the timing | The asker decides the timing |
As the table shows, the two are not rivals but complements. Each has its strengths and weaknesses.
When do webhooks work well?
Webhooks are the right choice for work where speed matters and events happen occasionally but carry weight:
- Payment confirmation: the order must be confirmed the moment the customer pays.
- Order cancellation: stopping an order canceled on the marketplace before it reaches the warehouse.
- Form submission: a request from the website landing in the CRM instantly.
- Shipment status change: passing delivery information to the customer right away.
Many payment providers and marketplaces support notifications like these. If support exists, using it also eliminates unnecessary polling traffic.
When does periodic polling make more sense?
- When the other system does not support webhooks, which is especially common with older ERP systems.
- When data changes in bulk at certain times, such as a daily price list.
- When real-time updates make no business difference, such as overnight reports.
- When your system cannot be opened up to accept incoming requests from outside.
Do not overdo the polling interval. Polling every minute strains the other system, and many services throttle such heavy traffic. Set the interval based on what the work actually needs; a few minutes may be enough for stock, once a day for product details. We gave examples of how these decisions are made between an ERP and an online store in our ERP e-commerce integration article.
The most robust setup uses both
The weakness of webhooks is that a message can get lost along the way. If the receiving system is down at that moment, there is a network outage or the message is processed incorrectly, the event is missed. Most providers retry a failed message several times, but that has limits too.
So the setup we recommend is this: day-to-day operations run on webhooks, while an occasional periodic check runs in the background. For example, payments arrive instantly via webhook, and at the top of every hour the last hour's payments are queried in bulk to see if anything was missed. If something was, it is filled in and logged. This gives you both speed and assurance. We explain other ways to spot these gaps in our integration error monitoring article.
What to watch when setting up a webhook
- Verification: Check that the incoming message really comes from the expected source. Most providers sign messages with a secret key; no action should be taken before the signature is verified.
- Duplicate messages: The same event may arrive twice. The system should recognize it and not process it a second time; outcomes like confirming the same payment twice are a headache.
- Quick response: Say "received" right away and do the heavy work in the background. Otherwise the sender times out and sends the message again.
- Logging: Keep each incoming message for a short time so you can look back when something goes wrong.
- Secure address: The webhook address should work only over an encrypted connection.
For a broader look at these topics, see our API security checklist.
How we do it at Globya
When starting an integration, we first answer two questions together for each piece of data: how fast does it need to be, and what happens if it is missed? Depending on what the other system offers, we choose webhooks, periodic polling or a combination of both. We handle the setup as part of our integration service and build in message logging and missed-event checks from the start. We do not leave the technical details to you; what matters to you is that the event reaches the right place on time.
Frequently asked questions
Do we need to change anything on our server to use webhooks?
You need an address that can receive the webhook message, is reachable from the internet and supports encrypted connections. Most web servers already have this; if needed, a small configuration change is made.
Is a webhook a paid service?
A webhook is a method, not a separate product. Whatever the provider's own terms of service say applies; most providers include it in their standard service.
What happens if a webhook message gets lost?
If a periodic check runs in the background, the missed event is caught at the next check. That is why we recommend setting up both together for critical processes.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.