Webhooks in ERP and accounting: which systems push events

A webhook is a mechanism that lets one system actively notify another when a specific event occurs. Instead of continuously querying an API to check whether data has changed, a webhook lets the source system push a notification as soon as something relevant happens, such as an invoice being created, a payment being booked or a customer record being updated.

Technically a webhook is usually an HTTP POST request sent to a predefined URL. The request contains information about the event and, depending on the system, additional context or data. This lets integrations react almost in real-time to changes while reducing the API traffic that polling causes. For integration-heavy environments, webhooks are a key enabler of scalable and responsive architectures.

ERP and accounting systems are often the system of record for critical business data. Changes in them usually have downstream effects on reporting, payments, CRM systems or operational workflows. Without webhooks, integrations rely on scheduled polling jobs that introduce delay, increase API load and complicate error handling.

Webhooks mitigate that by enabling near real-time updates and clearer event semantics. They make automation easier to build, reduce synchronisation latency and keep distributed systems consistent. In theory that makes them an ideal fit for ERP and accounting integrations. In practice their adoption in this domain has been slow.

Across ERP and accounting platforms two different webhook models have emerged, and understanding them is essential for designing reliable integrations.

App-based: one endpoint for every user

In an app-based model a software vendor configures a single webhook endpoint for an entire application. All events from all connected users are sent to that one endpoint, and each payload includes a user identifier so the receiving app can determine which user the event belongs to. This is common on accounting platforms with strong app marketplaces, such as QuickBooks Online and Xero. From the vendor’s perspective it simplifies management and scales well across thousands of small tenants. From yours it requires robust internal routing, security validation and user isolation.

User-based: a subscription per user

In a user-based model, subscriptions are created per user. Each one explicitly defines which events should be delivered and where they should be sent. This is more common in ERP and mid-market systems, where data isolation, permissions and compliance requirements are stricter. Systems such as Microsoft Dynamics 365 Business Central and weclapp follow this approach. It is more complex to manage and it offers finer control with clearer boundaries between user environments.

Implementations also differ significantly in how much data they deliver. Some systems use a ping-and-pull approach, where the webhook only signals that something has changed and includes user and object identifiers. The receiving system then fetches the full data through the API in a second step. This pattern is common in enterprise-oriented ERPs and keeps payloads small and secure.

Other systems include meaningful business data directly in the payload. That can reduce the number of follow-up API calls and simplify processing, and it also increases payload size and places more responsibility on the sender. In our experience even extensive payloads often still miss information a real use case needs, which means a second API call is usually necessary anyway.

Unifying webhooks across every ERP and accounting system solves coverage, and a callback URL is publicly reachable, which means anyone who learns it could POST a forged event to it. That is why every event Maesn delivers is signed with an HMAC-SHA256 signature in the X-MAESN-SIGNATURE header, so your endpoint can verify it came from us before acting on it.

The overview below shows which systems provide native, vendor-supported outbound webhooks and how each one implements them. Systems without official support are listed explicitly rather than left out, because their absence is the finding.

This is also the reason a build-versus-buy estimate for webhooks is usually wrong. Support is not a question you can answer once per vendor. It is a question per object, per model and per payload style, and the answer changes when a vendor ships a release.

A few ERP and accounting systems, such as Fortnox, use websockets instead of webhooks to deliver change events. Websockets establish a persistent, bidirectional connection that streams events in real time, whereas webhooks rely on discrete HTTP requests sent when an event occurs.

Websockets can provide very low latency, and they introduce additional complexity: the connection has to be kept alive, reconnect logic has to be handled carefully, and scaling becomes harder across many customers. Webhooks are stateless, easier to secure and simpler to operate at volume, which is why they suit cross-system integrations better, while websockets are typically used in more controlled or vendor-specific scenarios.

Even where systems support native webhooks, they often cover only a limited set of objects. It is common to see events for sales-related entities such as invoices or sales orders, while important purchasing objects such as purchase orders are not supported at all. That forces teams to combine webhooks and polling inside the same integration, which means two codepaths that fail in different ways.

Maesn addresses this by complementing native webhooks with synthetic webhooks. Unsupported objects are monitored through polling and emitted as unified webhook events, so coverage and behaviour stay consistent across every system.

Webhooks in ERP and accounting are fragmented, inconsistent and often missing entirely. Maesn answers that with user-based webhooks for every connected system, synthetic webhooks where native support is missing or partial, the same security-first ping-and-pull pattern everywhere and a consistent payload structure.

The result is that all webhooks behave the same across all systems. What your handler needs to know stops at the unified event model, and the differences catalogued above stay on our side of the connection, across every connected system.

Despite the advantages of event-driven integrations, many ERP and accounting systems still do not offer native, vendor-supported webhooks. That is often rooted in legacy architectures, a strong reliance on batch processing and strict audit or compliance requirements that make real-time event delivery harder to implement and maintain. Many products in this space were also designed around manual workflows rather than continuous system-to-system automation.

When native webhooks are missing, polling is often seen as the only viable alternative. It is technically straightforward, and it introduces delay, increases API traffic and makes integrations less reactive. Some systems, such as Odoo, close the gap with third-party or add-on solutions that simulate webhooks by polling internally and emitting events externally. Those improve responsiveness and typically come with recurring costs that often exceed 200 euros per user per month, which makes them expensive at scale. Most teams fall back to direct polling as the pragmatic option.

For teams building across multiple ERP and accounting systems, the challenge is not handling webhooks themselves. It is dealing with inconsistent models, different payload strategies and the frequent absence of any webhook support at all. A workable strategy has to abstract those differences, combine event-driven delivery with a fallback where events do not exist, and offer one way to consume changes across systems.