Webhook
A webhook is an HTTP request that a system sends, on its own, to a URL another system registered in advance, the moment a chosen event happens; the receiver is told as soon as it occurs, instead of having to ask on a schedule whether anything changed.
Submit a project See e-commerce and ERP integrationReviewed by Huy Nguyen (David), CEO · Updated 28 Oct 2026 · 5 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while scoping how two systems stay in sync.
Why does a webhook matter?
The alternative to a webhook is polling: a client calls an API over and over, on a timer, to check whether something new exists, which wastes calls and still leaves a gap between the change and the check that notices it. GitHub's own documentation about webhooks puts the contrast plainly: "With webhooks, you only need to express interest in an event once, when you create the webhook," after which "GitHub will send an HTTP request with data about the event to the URL that you specified." OutsourcingVN is operated by Netbase JSC, and the practical reason a buyer should care which route an integration uses is latency and load: an order or a stock change that a storefront or ERP needs to act on immediately is a webhook candidate, while a low-urgency field is often fine on a timer.
What is an example of a webhook in practice?
A store takes a payment and marks the order paid. Instead of an ERP calling the store's API every few minutes to check for new paid orders, the store sends a single HTTP request straight to a URL the ERP registered beforehand, carrying the order's identifier and its new status, the moment the payment clears. The ERP's endpoint receives that request, checks it, and creates or updates the matching order record; no part of the exchange waited for a scheduled check to run.
What are the common misreadings of a webhook?
A webhook is not an API a receiver calls when it wants data; it is closer to the reverse, a request the sender initiates toward a URL the receiver gave it in advance, which Shopify's developer documentation describes as "a performant alternative to continuously polling for changes to a shop's data." A webhook delivery is also not guaranteed to arrive exactly once: Shopify's own documentation says "Webhook delivery isn't always guaranteed," so a receiver that assumes every event lands precisely once, in order, with no repeats is building on an assumption the sender does not promise. And a webhook payload is not inherently trustworthy just because it arrived on the expected URL: GitHub's guidance on validating deliveries has a receiver compute its own signature from a shared secret and compare it, rather than trust the request on sight.
Plan the next step for your project
Common questions
By signature: GitHub has the sender compute a hash of the payload with a shared secret and send it in a header, which the receiver recomputes and compares using a timing-safe comparison rather than a plain equality check, per GitHub's documentation on validating webhook deliveries.
Shopify's documentation recommends a receiver run its own reconciliation job that periodically re-fetches data to stay consistent, and use a delivery identifier header to recognise and ignore a duplicate delivery of the same event.
Yes: Odoo 18.0's automation rules documentation lists an "External" trigger: "Trigger automated actions based on a specific event in an external system or application using a webhook," so the same pattern that sends data out of one system can also receive it into another.
Which decisions does a webhook affect?
Choosing webhook delivery, a scheduled sync, or both per data type is one of the decisions the e-commerce and ERP integration workflow settles in its sync-method step, and the Odoo API integration guide covers wiring an outbound event through Odoo's own automation rules when a custom application needs to be told rather than having to ask. Where the storefront runs on Shopify specifically, the Shopify and Odoo integration guide covers that platform's webhook reconciliation and API limits. A webhook delivery that a receiver must not apply twice is the subject the idempotency entry defines next. When you know which events your systems would need to notify each other about, describe them and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.