The common mistake: treating integration like a transport problem
A company can have a solid ERP, a well-selling online store and still operate badly. The reason is usually simple: integration is treated as a way to move data, when in reality it is a way to decide which process has authority.
When an order comes in through ecommerce, the system should do more than “send it” to the ERP. It should decide whether the order is confirmed immediately, whether stock is reserved, whether it waits for validation, whether it is split into several shipments, or whether it is blocked by a commercial issue. If that logic is not written down, the integration becomes a chain of patches.
My thesis is direct: in ERP and ecommerce, the value is not in synchronizing more objects, but in reducing operational ambiguity. A fast integration with weak governance often creates more rework than a smaller integration with clear rules.
Integrating systems without defining exceptions is a polished way to automate problems.
What must be decided before touching the API
Before discussing connectors, webhooks or middleware, five operating decisions should be closed.
- System of record by data type: who owns customers, pricing, stock, taxes, order status and invoicing?
- Commitment point: when does an order stop being editable and become an operational obligation?
- Exception handling: what happens with incomplete orders, negative stock, outdated prices or invalid addresses?
- Financial sequence: does the invoice follow payment, shipment or warehouse dispatch?
- Traceability: how can a case be reviewed without opening three screens and two spreadsheets?
If those answers do not exist, the project ends up discussing messages, queues and endpoints, when the real problem is business policy. That is why, in serious integrations, the most important document is not the technical diagram but the operating rules table.
It is also worth accepting an uncomfortable truth: not everything should be real-time. Some data needs immediacy, yes. But other flows work better in batches, with validation and reconciliation. Forcing everything to be instant usually increases fragility, cost and dependence on third parties.
Mini-case: when the “correct” stock was still not enough
A B2B and ecommerce distributor sold fast-moving products and a few critical SKUs. The problem was not the lack of integration, but the lack of shared criteria between sales, warehouse and finance.
The store showed available stock in real time, but the warehouse needed to reserve units for recurring orders and finance blocked certain dispatches because of credit risk. The result was online orders accepted and later impossible to fulfill without manual intervention.
The solution was not “sync better”. It was to redefine the rules:
- public stock separate from committed stock
- order confirmed only after credit validation for certain customers
- invoice generated by logistics events for some lines and by payment for others
- alerts when a manual override broke the normal sequence
The real improvement came from reducing improvisation. The connector still mattered, but it stopped being the center of the project.
The uncomfortable decision: sometimes you should accept less automation
There is a point many teams avoid: automating everything can make operations worse. If the business has many edge cases, complex returns, special pricing or customer-specific restrictions, full automation forces too many exceptions into the software.
That creates two risks:
- the integration becomes hard to maintain
- the team stops understanding what the system does in each case
In some contexts, it is better to automate 80% of the flow and leave 20% under operational review with clear queues, defined roles and internal SLAs. That is not a technical defeat; it is a way to protect continuity.
The indicators that automation is poorly designed are easy to spot: orders stuck without explanation, daily manual reconciliations, status changes nobody can audit, invoices rewritten and recurring tickets about “the system does not understand this case”.
How to design an integration that survives the operation
A useful integration is not measured by how many objects it synchronizes, but by how well it survives real business change.
Three criteria help a lot:
- Idempotency and safe retries: if a message is repeated, it should not duplicate orders or invoices.
- Observability: every event should be traceable from origin to final effect.
- Reconciliation: there must always be a way to compare expected state with actual state.
It also helps to define from the start which failures are resolved automatically and which require human intervention. That boundary is a design decision, not a technical detail.
The companies that execute these integrations best are not the ones that connect fastest, but the ones that first stabilize their operating model. Once that is clear, technology stops being friction and becomes a control layer.
At Codefuente, we usually start with those rules before the connector, because in ecommerce and ERP the right integration is the one operations can sustain tomorrow, not just the one that works today.