Webhook
A webhook is an automatic notification that one system sends on its own via HTTP to a stored address of a target system when a specific event occurs. Instead of actively polling, the target system is informed immediately – in an ERP context about new orders, payments or stock changes, for example.
A webhook is an automatic callback between two software systems: as soon as a defined event occurs in a source system – for example a new order, a successful payment or a changed delivery address – that system sends a small message via HTTP, on its own initiative, to a previously stored web address (the “callback URL”) of another system. The target system, such as an ERP, thereby learns of the event immediately, without having to ask for it. The name alludes to a “hook” that you attach to someone else’s code in order to be notified when certain events occur.
The decisive difference from a classic query lies in the direction: with a webhook the target system is informed (push) instead of knocking at short intervals itself (pull). That is why the webhook is considered the most efficient way to pass on events in near real time. In the ERP and e-commerce world, webhooks are the standard way for shop, marketplace, payment provider and shipping service to notify the inventory management system immediately when something relevant happens.
At a glance
- Webhook = automatic push notification on an event, sent via HTTP to a callback URL
- Core principle “don’t call us, we’ll call you”: the source system reaches out, the target system waits
- Delivers events in near real time – ideal for orders, payments, stock changes
- Saves compute load and data traffic compared with polling
- Secured via secret signatures, HTTPS and a retry logic in case of errors
How a webhook works
A webhook always consists of three building blocks: the triggering event, the callback URL and the transmitted payload. First you store a URL in the source system – such as the online shop or the payment provider – to which notifications should go, and you select which events should trigger them. When the event occurs, the source system sends an HTTP request (usually a POST) to exactly this address. The message body contains the payload: a compact, machine-readable data set – typically in JSON format – that describes what happened, such as the order number, the line items and the amount.
The receiving system accepts the request at an endpoint set up specifically for this purpose, processes the data and confirms receipt with an HTTP status code such as 200. If this confirmation is missing – because the endpoint was briefly unreachable – most providers attempt delivery again several times (retry), often with growing intervals. This way, events are not lost even during short outages.
Security: signatures and retries
Because a callback URL can in principle be called by anyone on the internet, webhooks need to be secured. A signature is common: the source system computes a checksum from the payload and a secret key and sends it in the header of the request. The target system recalculates the same checksum and accepts the message only if the two match – this way forged calls can be rejected. In addition, the transmission runs over HTTPS, and the endpoint should process identical events without a duplicate effect (idempotency), since a retry can deliver the same message a second time.
Webhook vs. API polling: push instead of pull
To achieve the same purpose – obtaining data from another system – there are two fundamental approaches. With polling, your own system calls the source system’s API at fixed intervals and asks: “Is there anything new?” Most of the time the answer is “no”, so many requests run into the void. If you poll rarely, the data is out of date; if you poll frequently, you create unnecessary load and quickly hit the interface’s rate limits.
The webhook reverses this principle: the target system waits passively and only becomes active when the source system actually reports an event. The result is lower load, less data traffic and a freshness close to real time. The price for this is a publicly reachable, permanently available endpoint that reliably accepts incoming notifications. In practice, many integrations combine both: webhooks for the fast reaction to individual events and an occasional poll as a safety net to catch up on missed notifications.
Webhooks in the ERP system
In the ERP, webhooks are the link for a responsive data flow between inventory management and the rest of the system landscape. A modern retailer runs shop, marketplaces, payment and shipping in parallel – and each of these systems can notify the ERP via webhook as soon as something happens. When an order comes in at the shop, a webhook reports this to the ERP immediately, which creates the order, reduces the stock and triggers picking. When a payment provider books a payment, another webhook marks the order as paid and releases it for shipping.
The outbound direction works in the same way: if the stock of an item changes in the ERP, a webhook can inform the connected sales channels so that the stock synchronization takes effect everywhere and oversells are avoided. Because webhooks are usually configured via a system’s REST API, both concepts belong closely together: the API provides the data and the management of the subscriptions, while the webhook actively delivers the events.
The role of middleware and iPaaS
Not every ERP can accept every webhook directly or translate it into arbitrary target formats. This is where middleware or an iPaaS platform comes in: it accepts the webhook notifications centrally, filters and transforms them and forwards them in the appropriate format to the ERP or further systems. This decouples the systems from one another, makes errors traceable and spares you from having to program a dedicated endpoint for every new connection.
Limits and typical pitfalls
As efficient as webhooks are, they also impose requirements. The endpoint must be permanently reachable – if it fails, notifications are initially lost and are only restored through retries or a downstream poll. Because delivery can occur multiple times, the receiver must process the same notification without a duplicate posting. And because events can arrive in unpredictable waves – for example on a promotion day with many orders – the endpoint must absorb short-term load peaks, ideally by only accepting the notification quickly and placing the actual processing into a queue.
A further point is the order: webhooks do not always guarantee that events arrive in the order in which they were triggered. For a clean interplay, the receiver should therefore check, based on timestamps or status fields, which state is the most current. These requirements are manageable, but they belong in every integration and implementation project from the very start.
Example
Example: an incoming payment triggers shipping
An online retailer for sportswear uses an external payment provider. A customer orders a jacket and pays by instant bank transfer. As soon as the payment is confirmed, the payment provider sends a webhook to the callback URL stored in the ERP – with the order number and the note “paid” in the payload.
The ERP verifies the signature that was sent along, assigns the notification to the open order and sets it to “paid”. This removes the block on shipping, the order automatically moves into picking, and a shipping label is generated. Without a webhook, the ERP would have to poll the payment status every minute; with a webhook the release happens within seconds of the incoming payment – entirely without manual intervention.
Frequently asked questions
Related services
Questions about Webhook in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.