eCommerce integration with ERP, PIM and WMS

An eCommerce operation does not live in isolation. Products and prices may come from a PIM or ERP, stock from a WMS, orders from the shop and documents from the ERP. The business problem is not simply “connecting two APIs”; it is avoiding manual copies, inconsistent data and blocked orders when systems and responsibilities do not line up.

Operational situations to resolve

• The same data is entered or corrected in several systems.
• Stock and prices differ across the shop, ERP, marketplaces and warehouse.
• Orders or documents stop moving without a clear place for the team to intervene.
• An integration exists but has no owner, monitoring or recovery procedure.

Data and processes to synchronise

The map establishes which system governs each data domain, where the data needs to go and which operating problem must be controlled.

How the solution is selected

The choice starts with the processes to support, authoritative sources and system constraints. For each flow I assess direction, frequency, volumes, transformations, edge cases, access security, existing tools and responsible people. The appropriate outcome may be an existing product, a configured connector, middleware or a focused integration.

For Shopify, Shopify integrations with ERP, PIM and marketplaces covers platform-specific constraints. When the work also involves architectural choices and priorities across several initiatives, eCommerce technical consulting and architecture is the broader starting point.

When a connector is enough and when a custom integration is needed

An existing connector may be the simplest solution when it covers the required data and rules, can handle expected volumes, exposes errors and has sustainable maintenance costs and ownership. Mapping, frequencies, API limits and recovery options still need to be checked before adopting it.

A custom integration may be useful when data needs specific transformations, several systems must coordinate, errors require dedicated operating procedures or technical constraints fall outside the connector. It is not the automatic choice: configuration, extension or replacement of existing tools should also be compared, including initial cost and long-term continuity.

The intended operating model

Each data domain needs an authoritative source, destination, frequency and transformation rules. Errors need to be visible, classifiable and recoverable; the team needs to know who intervenes and how systems are reconciled.

What the client receives

• A map of the systems, data and flows within scope.
• Defined authoritative sources and operational responsibilities.
• Requirements, edge cases and verifiable acceptance criteria.
• A delivery plan covering priorities, dependencies and release steps.
• The integration, connector or middleware where included in the project.
• Monitoring, notifications and procedures for handling errors.
• Technical and operational documentation for internal teams and suppliers.

Actual deliverables depend on the project and are defined before implementation, keeping scope, exclusions and responsibilities clear.

Technical delivery details

• Synchronisation of catalogues, prices, availability, customers, orders and documents.
• Middleware where systems cannot communicate directly.
• Webhooks, queues and scheduled jobs aligned with frequency and reliability needs.
• Retries, idempotency, notifications, operational logs and reconciliation tools.
• Documentation of flows, dependencies, ownership and intervention procedures.

APIs, webhooks, queues and error recovery

APIs and webhooks are exchange tools. When reliability and volumes require it, queues and scheduled jobs decouple systems and control load. Retries and idempotency prevent a temporary error or repeated message from creating duplicates; logs and reconciliation help identify differences and return data to a consistent state.

How the work proceeds

I map the current flow, define architecture and acceptance criteria, delimit a verifiable first release and move the system into production with monitoring and documentation. The broader process is described on the Method page.

What I handle personally

I handle data mapping, architecture, specifications, implementation and verification. Where internal teams or suppliers are involved, I make technical boundaries and responsibilities explicit. For flows that reach warehouses and carriers, eCommerce logistics consulting also accounts for operational consequences.

Relevant published work

The Portfolio documents Kikkiline’s Shopify migration with Danea Easyfatt integration and a JSON feed export. These are facts already published in the project entry.

Technologies and systems

REST and GraphQL APIs, webhooks, RabbitMQ, Symfony Messenger, PHP/Symfony, Node.js, Golang, Akeneo, ERP, PIM, WMS and JSON, XML or CSV formats. Technology is selected after the flow and its requirements are defined.