Connecting to your ERP: one API, not per-client integrations

"Does it integrate with my ERP?" is one of the first questions a serious manufacturer asks of any new software. It is a reasonable question — nobody wants an island. But the answer that sounds best ("yes, we'll build a connector for your ERP") is actually the worst, leading to a tangle of per-customer integrations. The sustainable answer is one generic API that any ERP can connect to. Here is why that approach serves you better.

What "integrate with my ERP" usually means

When a manufacturer asks for ERP integration, what they usually need is straightforward: get data out of the formulation system into the ERP (ingredients, formulas, costs, documents) and get data in (perhaps inventory or supplier data). In other words, structured import and export, and a way for systems to talk. Most "ERP integrations" are really this — mappable data flowing between systems — not a deep, bespoke wiring of two specific products.

Recognising this reframes the problem. If the need is data flowing in and out in a mappable way, then the answer is a good API and import/export, not a custom connector for each customer's exact ERP.

The per-client integration trap

Building a dedicated integration for each customer's ERP seems responsive but is a trap, the same way per-client custom documents are. Every bespoke connector is code to build, maintain, and update as both systems evolve. With many customers on many ERPs, you accumulate a pile of fragile, individually-maintained integrations — expensive, brittle, and never finished.

This does not scale. The right architecture avoids per-client integrations entirely in favour of one generic layer that every customer uses.

One public API, any ERP connects

The sustainable approach is a single public API: a documented, versioned interface, with authentication and rate limiting, that any ERP or middleware can connect to. Instead of the vendor building a connector per customer, each customer (or their integration tooling) connects to the one API. This answers the vast majority of "integrate with my ERP" needs through one maintainable layer rather than many bespoke ones.

A public API is generic by design: it does not care which ERP is on the other end. SAP, ODOO, ORACLE or a smaller ERP, custom middleware — they all speak to the same API. One thing to build and maintain, infinite things it can connect to.

Webhooks and mappable import/export

Two companions complete the picture. Webhooks let the system notify external tools when something changes — an ingredient updated, a spec generated — so the ERP can react without polling. And mappable import/export handles bulk data flows in the common shapes ERPs expect. Together with the API, these cover the real integration needs: query and update via the API, react to changes via webhooks, move data in bulk via mappable import/export.

When a dedicated connector makes sense

There is a place for a dedicated connector to a major ERP — but only when enough customers share that ERP to justify it, and always built on top of the public API, never bypassing it. The discipline is: the API is the foundation everyone uses; a connector is a convenience layer over it for a popular ERP, not a one-off bespoke wiring. This keeps even the connectors maintainable, because they sit on the same generic API.

Because integration needs vary, confirm the approach that fits your specific ERP and data flows rather than relying on a general summary.

Where Lemoniq fits

Lemoniq's integration approach is one generic layer: a public API with authentication, rate limiting, and versioning that any ERP or middleware connects to, plus webhooks for change notifications and mappable import/export for bulk data. This answers the great majority of "integrate with my ERP" needs through one maintainable interface — never per-client integrations. Where a dedicated connector to a popular ERP is warranted, it sits on top of the API, never bypassing it.

The takeaway

"Integrate with my ERP" usually means mappable import/export and an API, not a bespoke connector per customer — and building per-client integrations is an unscalable trap. One public API, with webhooks and mappable import/export, lets any ERP connect through a single maintainable layer, with dedicated connectors only when justified and always built on the API. One generic layer, any ERP, is the sustainable way to integrate.

Lemoniq offers one public API, webhooks, and mappable import/export — so any ERP connects through a single layer, never per-client integrations. We solve this exact problem. See how it works