How we design ERP integrations: no magic, no vendor lock-in
Integrating an ERP with WooCommerce is one of the most complex projects in eCommerce, but the difficulty rarely lies where the client expects it. The API is not the hard part. The hard part is that the data on the two sides almost never matches, and every company has spent years developing its own unique way of keeping it. That is why it can’t be done “from a template,” and that is exactly why we follow a repeatable process instead of improvising.
Below we show how we work on an integration like this: from day one, when we don’t write a single line of code, to monitoring that keeps running long after launch. No magic and no beating around the bush, because this is an area where transparency matters more than catchy slogans.
We start with a data audit, not with code
Before the first line of the integration is written, we usually spend two or three days understanding how the client’s ERP really stores products, orders and business partners. This is not a formality; it is the most important stage of the whole project. Without it, writing code is guesswork, and in integrations guesswork ends with stock levels out of sync and orders stuck in the wrong statuses.
Importantly, every implementation is different, even within the same ERP system. Two companies on the same Subiekt or Comarch can have completely different field mappings, different status dictionaries and different rules, because each one built its process its own way. The data audit is there so we understand that specific reality before we build anything on top of it.
Field mapping is a job for a human, not a script
Once we know what the data looks like, we move on to mapping, that is, deciding which field on the ERP side corresponds to which field in the store. It sounds like the perfect task for automation, and that is exactly why so many vendors have failed at it. Automation handles the typical case but falls apart at the first exception, and in business data, exceptions are the rule.
That is why we do the mapping by hand, together with the client, on real records rather than a clean example from the documentation. We go through unusual products, historical orders and odd statuses, because they decide whether the integration will be reliable or will generate silent errors. This stage is less impressive, but it is what separates an implementation that works from one that only looks finished.
Architecture: a queue, idempotency, logs
We build the synchronization itself as a simple but resilient mechanism: a job queue with a one-way data flow and a single, unambiguous source of truth for each data type. The ERP owns products and stock levels, WooCommerce owns orders. This way the two sides don’t overwrite each other, and conflicts disappear before they arise.
Every operation is idempotent, meaning it can be safely repeated without the risk of duplicating data, and every operation leaves a trace in the log. When the ERP stops responding for a moment, jobs wait in the queue instead of getting lost, and once the connection is back, everything completes on its own. These invisible decisions are what make an integration hold up during a sales peak, not just on a quiet Tuesday.
Monitoring is not optional
An integration that works today will not necessarily work a month from now. An ERP update, a configuration change or a new product type is enough for something to stop adding up. That is why we never consider an implementation finished without a monitoring layer that tells us about a problem before your customer notices it.
In practice, we close every implementation by setting up alerts for synchronization errors and a simple dashboard that shows what was synchronized and when. The point is not to stare at charts. The point is that any error arrives as a ticket, not as a surprise you discover when the stock count doesn’t match.
No vendor lock-in: the code stays yours
There is one more principle that sets our approach apart from many others: what we build should remain yours. We don’t lock the integration inside a proprietary plugin that nobody but us understands and that ties you to a single vendor forever. We write code so that it can be maintained and developed further, including by another team.
On top of that come documentation and knowledge transfer, because for us “finished” means your company is genuinely in control of what it received. We want to be your partner because we work well together, not because you have no way out. That is more honest and, frankly, healthier for both sides in the long run.
Planning an ERP integration and don’t want to depend on a single vendor? Request a free quote or write to us, and we will break your case down piece by piece before we write a single line of code.
