Webhooks in ERP and accounting: which systems push events

A webhook lets one system notify another when something changes. You register a URL once, and the source system sends a request to it as soon as something relevant happens, such as an invoice being created, a payment being booked or a customer record being updated. Nothing has to query an API on a schedule to find out.

Three terms carry this article, and each one names a different thing. The event is the change in the source system, the invoice that was created, and it is what triggers a delivery. The webhook is the HTTP POST request that reports this event to the URL you registered. The payload is the body of that request, and how much it carries differs from system to system.

Because the source system reports changes as they happen, an integration can react within seconds and stops sending requests that return nothing new. For an integration that keeps data in sync for many customers, that decides between constant traffic and traffic only when there is something to fetch.

ERP and accounting systems are often the system of record for critical business data. A change there usually has effects downstream, on reporting, payments, CRM systems or operational workflows. Without webhooks, an integration relies on scheduled polling jobs, which add delay, raise API load and make error handling harder.

Webhooks shorten that path. A change reaches the integration within seconds, each webhook names the object that changed, and the systems involved stay consistent with less traffic between them. That would make webhooks the default for ERP and accounting integrations, and in this domain their adoption has been slow.

Across ERP and accounting platforms two different webhook models have emerged, and which one a system uses decides how much routing and isolation you own.

App-based: one endpoint for every user

In an app-based model the software vendor configures a single webhook endpoint for the whole application. Webhooks for all connected users arrive at that one endpoint, and each payload carries a user identifier so your app can tell which user the event belongs to. This is common on accounting platforms with strong app marketplaces, such as QuickBooks Online and Xero. For the ERP vendor it is simple to manage and scales across thousands of small companies. For you it means routing every webhook to the right user, verifying it and keeping users isolated from each other.

User-based: a subscription per user

In a user-based model a subscription is created per user. Each one defines which events are delivered and to which URL. 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. There are more subscriptions to manage, and in return each one has a clear boundary around the data of one user.

Systems also differ in how much data a webhook carries. Some use ping and pull: the payload only signals that something changed and names the user and the object, and the receiving system fetches the full record through the API in a second call. This pattern is common in enterprise-oriented ERPs and keeps payloads small.

Other systems put business data directly into the payload. That can save the follow-up call and simplify processing, and it makes the payload larger and the sender responsible for more. In our experience even extensive payloads often miss a field a real use case needs, so the second API call usually happens anyway.

The overview below shows which systems publish native, vendor-supported outbound webhooks and which model and payload each one uses. Systems without them are listed by name, because for an integration their absence is as much a finding as a webhook.

This is also why a build-versus-buy estimate for webhooks is usually wrong. Support has to be answered 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, deliver change events over websockets. A websocket is a persistent, bidirectional connection that streams events as they happen, where a webhook is a single HTTP request per event.

Websockets can deliver with very low latency, and they cost more to operate: the connection has to be kept alive, reconnects have to be handled carefully and scaling gets harder with every customer. Webhooks are stateless, easier to secure and simpler to run at volume, which is why they suit cross-system integrations better. Websockets show up mostly in controlled or vendor-specific scenarios.

Even where a system supports native webhooks, they often cover only part of its objects. Events for sales-side entities such as invoices or sales orders are common, while purchasing objects such as purchase orders often have no event at all. An integration then combines webhooks and polling for the same customer, which means two code paths that fail in different ways.

The same object-level split applies to what maesn delivers. Each system page in the integration directory shows, object by object, which objects send webhooks through maesn and which ones you keep current with a scheduled read.

Despite the advantages of event-driven integrations, many ERP and accounting systems still offer no native, vendor-supported webhooks. The reasons are usually legacy architectures, a strong reliance on batch processing and strict audit or compliance requirements that make real-time delivery harder to build and maintain. Many products in this space were also designed around manual workflows, with system-to-system automation added later.

Where native webhooks are missing, polling is the remaining option. It is technically straightforward, and it adds delay, raises API traffic and makes an integration slower to react. Third-party add-ons that simulate webhooks by polling internally exist for some systems, and their recurring cost per user adds up at scale. Most teams poll directly.

An integration across many systems therefore has to cover both cases: webhooks where a system sends them, and a scheduled read with a modification filter where it does not, behind one way of consuming changes.

Through maesn you create a subscription per customer with one endpoint, and webhooks arrive at your callback URL in the same payload shape, whichever system they came from. An app-based vendor’s single endpoint stops being routing work in your code, because the subscription already belongs to one customer.

The payload follows ping and pull on every system: it names the object that changed, and you read the object through the Unified API. What your handler needs to know stops at the unified event model, and the vendor differences catalogued above stay on our side of the connection.

Where a system or an object sends no webhook through maesn, the same API serves the scheduled read. A lastModified filter returns only the records that changed since your last call, so each run stays small.

A callback URL is publicly reachable, so anyone who learns it could POST a forged webhook to it. Every webhook maesn delivers is therefore signed with an HMAC-SHA256 signature in the X-MAESN-SIGNATURE header, and your endpoint verifies it before acting on the payload.