ERP and ecommerce integration is often introduced as a technical bridge: products and stock move out, orders move back. That description is correct and incomplete.
The difficult part is agreeing what the information means, which system controls it and what should happen when the normal path breaks. Projects usually struggle at those boundaries rather than in the basic API call.
Starting without data ownership
If staff can edit the same product field in both systems, the integration needs to decide which change wins. Without an agreed answer, it may overwrite valid work or create a cycle of updates.
Create a field-level ownership map for products, pricing, customers, orders and statuses. Include who is allowed to make the change, not only which database stores it.
Using unstable identifiers
Names and email addresses feel convenient, but they can change or collide. Products, companies, contacts and orders need stable identifiers and a reliable cross-reference between systems.
This becomes essential during migration, when an existing online customer must be linked to the correct ERP account without creating duplicates.
Designing only the happy path
A successful test order with one product proves very little. Integration testing should include:
- out-of-stock and backordered products;
- customer-specific pricing;
- multiple tax and currency scenarios;
- address changes and partial fulfilment;
- failed or delayed payments;
- duplicate requests and network timeouts;
- products that have been merged or discontinued;
- refunds, credits and cancellations.
The business team usually knows these exceptions. Bring them into discovery early.
Treating sync frequency as a technical setting
Data should move at a frequency that matches the operational risk. Orders may need to appear within moments. Large image and description updates can run in a scheduled batch. Stock may need faster updates during busy periods than the rest of the catalogue.
Define acceptable delay for each flow, then design triggers and monitoring around it.
Hiding errors from the people who can fix them
An integration can be technically active while records are quietly failing. Staff need a clear queue tied to recognisable products, customers or orders.
Errors should say what needs attention. “Invalid payload” helps a developer; “Customer 4102 has no valid delivery address” helps operations resolve the item. Safe retries should not create duplicates.
Launching without reconciliation
Before go-live, compare totals and samples across systems. Count products by status, validate price sets, review customer mappings and reconcile order values. After launch, keep a temporary daily review until the team trusts the flow.
Reconciliation is also useful long term. Automated checks can flag missing orders, stale stock updates or unexpected changes in record volume.
Forgetting the ownership after launch
Both platforms will change. APIs release new versions, business rules evolve and teams add fields. Decide who monitors the integration, how releases are tested and which supplier coordinates when an issue crosses system boundaries.
A staging environment, activity logs and current documentation turn future changes into controlled work instead of emergencies.
Treat it as an operational product
An integration is not finished when the first record moves. It is a small operational product with users, exceptions, support needs and a roadmap.
Web Paste designs ERP and ecommerce integrations with the surrounding storefront and staff workflow in view. Our Cintesi project connects Accredo and BigCommerce across product data, customer pricing, stock and orders, with the commerce experience and middleware planned together.
