Pimcore integration with ERP, e‑commerce and other systems
Aurora Creation designs and delivers connections between Pimcore and ERP, WMS, an e‑commerce platform, marketplaces and other systems.
We establish where data originates, which direction it should flow, and how often it should be synchronised.
- New integrations
- Rebuilding existing connections
- API and Pimcore Datahub
- Imports and exports
- Synchronisation and error handling
Every type of data needs an established source and owner
A product description can be edited in Pimcore, the price in ERP, stock levels in WMS, and an order originates in the store. The integration has to reflect that split.
Problems start when two systems can overwrite the same information, or no team knows where the correct version of the data actually lives. Duplicates appear, updates stay incomplete, and channels drift apart.
Before designing the connections, we establish ownership for every set of data. Only afterwards do we define the API, the synchronisation frequency and the processing rules.
| Type of data | Possible source | Typical recipients |
|---|---|---|
| Identifiers and core product data | ERP or Pimcore | Pimcore, the store, WMS |
| Descriptions, attributes, translations and media | Usually Pimcore | The store, marketplace, catalogues |
| Prices and trade terms | ERP or a pricing system | The store, B2B, marketplace |
| Stock and availability | WMS or ERP | The store, marketplace |
| Orders | The e‑commerce platform | ERP, WMS, CRM |
| Customer and B2B account data | CRM, ERP or e‑commerce | Sales and service systems |
Identifiers and core product data
Possible source
ERP or Pimcore
Typical recipients
Pimcore, the store, WMS
Descriptions, attributes, translations and media
Possible source
Usually Pimcore
Typical recipients
The store, marketplace, catalogues
Prices and trade terms
Possible source
ERP or a pricing system
Typical recipients
The store, B2B, marketplace
Stock and availability
Possible source
WMS or ERP
Typical recipients
The store, marketplace
Orders
Possible source
The e‑commerce platform
Typical recipients
ERP, WMS, CRM
Customer and B2B account data
Possible source
CRM, ERP or e‑commerce
Typical recipients
Sales and service systems
The split above is an example. The right map depends on the processes and ownership inside a specific organisation.
If the data model inside Pimcore itself hasn't been designed yet, the scope should start with a Pimcore implementation.
Which systems can Pimcore be integrated with?
The scope of an integration follows the company's processes. Connecting Pimcore to a store looks different from synchronising with ERP, and distributing data to several marketplaces looks different again.
Below are the systems that most often take part in such a project, and what they exchange data with Pimcore for. During the analysis we also check the dependencies between them: changing an identifier in ERP can affect a product in Pimcore, a marketplace listing, a warehouse index and an order line.
Systems in the architecture
- ERP
- Core product data, indexes, prices, business partners, trade terms and sales documents. The scope depends on the role ERP plays in the organisation.
- Magento 2
- The store receives product data, attributes, categories and media, while orders and selected customer data can flow back to the operational systems.
- Shopify
- The same split against a different platform data model: Pimcore prepares the range of fields and media that Shopify can accept and show in the offer.
- WMS
- Stock levels, locations, reservations, fulfilment status and availability information.
- CRM
- Account data, segments, B2B customers, account managers and the information the sales team needs.
- Marketplaces
- Pimcore can prepare separate names, descriptions and attributes for a specific channel. The integration should also record publication status and why a listing was rejected.
- Data warehouses and BI
- Exports of product data, completeness statuses and change history for reporting — usually in batches and in one direction.
- Supplier systems
- Product sheets, attributes and media from manufacturers or importers, taken in whatever formats they are published in and mapped onto your own model.
- Mobile apps
- Sales, service and warehouse apps pulling data through an API, usually in a narrower scope than the store.
- Product services
- Comparison sites, trade portals and product-sheet services, each expecting its own set of fields and its own category structure.
- Catalogues and DTP
- Data and media used to build catalogues, product sheets, distributor materials and print.
- Product feeds
- Files generated for advertising, comparison sites and partners: their own range of fields, their own format and their own publication schedule.
This is not a catalogue of ready-made connectors. How an integration is built depends on what a specific system exposes — its API, formats, limits, authentication and ability to notify about changes. The same kind of system at two companies can need two different solutions.
How does data flow between Pimcore, an ERP and an online store?
The basic model is simple: the ERP and the suppliers feed Pimcore, Pimcore organises the information and passes it to Magento 2, Shopify, marketplaces, catalogues and apps.
In specific integrations some of the data flows the other way — orders, customer data or publication statuses go back to the systems that answer for them. The direction is settled separately for each kind of data, together with its source and owner.
Example directions
ERPPimcore
Indexes and core product data, and depending on the architecture prices or stock levels too. Pimcore treats them as read-only where the ERP remains their source.
Pimcoree‑commerce
Descriptions, attributes, product relations, media and translations — in the scope and format a given channel expects, once the publication conditions are met.
e‑commercePimcore
Data that needs syncing back, where the project's architecture provides for it: publication statuses, content created in the channel, or information about rejected listings.
source systems
- ERP
- WMS
- CRM
Pimcore
- E‑commerce
- Marketplace
- Catalogue and DTP
channels and recipients
Prices and stock levels can go from ERP or WMS straight to the store, without passing through Pimcore.
Pimcore Datahub — GraphQL, REST, webhooks and exports
Pimcore does not force one way of exchanging data. Datahub makes it possible to build GraphQL endpoints, the platform itself exposes an API, and the ecosystem includes webhook mechanisms and the remaining integration adapters.
We match the mechanism to the recipient and to how quickly it needs the data. One project uses several at once: the store pulls data through an API, the warehouse gets a file overnight, and a marketplace is notified when a photo changes.
What we use each mechanism for
GraphQL
The recipient decides which fields and relations it pulls in a single query. It suits apps and frontends that need a narrower scope than a full product export.
REST
Simple, predictable operations on objects and assets — convenient for systems that expect a classic API and have handled one for years.
Webhooks
A notification about an event instead of asking “has anything changed?” on a timer. They shorten the gap between a change in Pimcore and an update in the channel, and take the load off polling.
Data exports
Files in an agreed format and on an agreed schedule, for recipients with no API or deliberately working in batches: warehouses, catalogues, feeds, trade partners.
Separate endpoints per recipient
Each channel gets its own range of fields, its own translations and its own visibility rules. A change for one recipient leaves the others alone, and permissions and limits are granted per endpoint.
Not every integration goes through Datahub. Some connections are built as a custom connector, some as an import on the target system's side, and some rest on queues — the choice follows from the project's architecture, its volume and its response-time requirements. The rules we settle before development are in the section on integration decisions.
Integrating Pimcore with Magento 2 and Shopify
The split of responsibility is the same on both platforms: Pimcore holds the product information, and the store answers for presenting the offer and running the sale. What differs is the range of data each platform can accept.
Pimcore
stores and manages
- products
- attributes
- categories
- descriptions
- product relations
- media
- translations
- channel-specific data
Magento 2 and Shopify
answer for
- presenting the offer
- search and navigation
- cart and checkout
- the prices the customer sees
- promotions and sales rules
- customer accounts
- orders and payments
- post-purchase service
How each kind of data is synchronised
- Products
- A record in Pimcore has its counterpart in the store, matched on an agreed identifier. New products are created only once the completeness conditions are met.
- Categories
- The store's structure can differ from the one in Pimcore. The synchronisation then uses a separate tree assigned to the channel rather than the internal one.
- Attributes
- Fields and dictionaries are mapped onto the platform's attributes together with units and types. A value outside the dictionary is a validation error, not a new value in the store.
- Images
- Media travel from the DAM with their order, their roles (main image, gallery) and their alternative text. Only the files that changed are sent again.
- Documents
- Manuals, certificates and datasheets reach the store as files linked to the product or as links, depending on what the platform supports.
- Language versions
- Translations go into the right store views or Shopify markets. A missing translation is visible in Pimcore before publication rather than after it.
- Channel-specific data
- Shortened names, different descriptions or a narrower set of attributes are prepared in Pimcore as channel data — the store does not have to override them on its own side.
The scope and the way the connection is built depend on the platform version and its data model. We describe the services for both environments separately: Magento 2 and Shopify.
The basic flow is easy. Scope is revealed by the exceptions
Sending a valid product from one system to another is rarely the hardest problem. The integration also has to know what to do with incomplete data, a duplicate, an authorisation error or a system that isn't responding.
Before development starts, we settle rules that can later be tested unambiguously. The client's team sees how the data will be processed and which decisions stay on their side.
- 01
Source and owner of the data
Which system creates the information, and who is allowed to change it?
- 02
Identifiers
How is the same product, variant, customer or order recognised across different systems?
- 03
Mapping and transformations
How should fields, units, dictionaries and relations be converted or transformed?
- 04
Direction and timing of synchronisation
Is data pulled on a schedule, pushed on an event, or read on demand?
- 05
Validation
Which data is required, and what happens when a record doesn't meet the rules?
- 06
Errors and retries
Which operations can be retried automatically, and which need a human decision?
- 07
Access and security
How are permissions, keys, tokens, data scope and environments handled?
- 08
Launch and data comparison
How will we verify that both systems hold matching information after go-live?
We run the project from a data map to a controlled launch
We confirm the scope and the implementation estimate after checking the systems, the interfaces available and the data quality. An earlier quote would rest mostly on assumptions.
- 01
Recognising the systems and the process
We check which systems take part in the process, who manages them and which interfaces are available. We collect sample data, documentation and technical constraints.
ResultA map of systems, a list of dependencies and the areas that need a decision.
- 02
Data sources and ownership
We establish the data sources, the direction of flow, identifiers, update frequency and business owners.
ResultA responsibility matrix and a flow map.
- 03
Technical specification
We describe endpoints, events, formats, transformations, validation, permissions, error handling and monitoring requirements.
ResultThe implementation scope, acceptance criteria and an updated estimate.
- 04
Implementation and testing
We build the connections and test valid data, edge cases, system unavailability and error response.
ResultA working integration on the test environment and a test report.
- 05
Pilot and starting data
We launch the flow on a limited data set or a chosen channel. We compare results against the sources and fix discrepancies.
ResultConfirmed readiness to launch the full scope.
- 06
Production, monitoring and documentation
The integration goes live according to the agreed plan. We document the configuration, dependencies, procedures and how to diagnose problems.
ResultA working connection and the materials needed to maintain it going forward.
The integration covers data flow, error control and documentation
The connection has to be safe to launch, safe to monitor and possible to develop further. That is why the scope covers not only the data exchange, but also validation, error handling, security, testing and documentation.
| Area | Result |
|---|---|
| System analysis | A list of systems, owners, interfaces and constraints |
| Data map | Sources, recipients, identifiers and flow directions |
| Data contracts | Message format, required fields, versioning and examples |
| Mapping | Transformation rules for fields, dictionaries, units and relations |
| Endpoints and connectors | Implementation of the connections defined by the accepted architecture |
| Security | Access model, authentication, permissions and how secrets are stored |
| Schedule or events | Rules for triggering synchronisation |
| Error handling | Validation, logging, retries, alerts and discrepancy reports |
| Testing | Valid scenarios, edge cases and system unavailability |
| Launch | A rollout plan, data control and a rollback procedure |
| Documentation | A description of the architecture, configuration, dependencies and operating procedures |
System analysis
A list of systems, owners, interfaces and constraints
Data map
Sources, recipients, identifiers and flow directions
Data contracts
Message format, required fields, versioning and examples
Mapping
Transformation rules for fields, dictionaries, units and relations
Endpoints and connectors
Implementation of the connections defined by the accepted architecture
Security
Access model, authentication, permissions and how secrets are stored
Schedule or events
Rules for triggering synchronisation
Error handling
Validation, logging, retries, alerts and discrepancy reports
Testing
Valid scenarios, edge cases and system unavailability
Launch
A rollout plan, data control and a rollback procedure
Documentation
A description of the architecture, configuration, dependencies and operating procedures
Ongoing care for connections that are already running is covered by our Pimcore maintenance service.
How much does a Pimcore integration cost?
We do not give a single price, because two integrations under the same name can differ several times over in effort. Below are the ten things that decide it — each one written so you can look for it in your own project.
What decides the estimate
- The number of systems integrated
- Every system brings its own API, authentication, limits and owner on the other side. Three connections are not three times one — the order and the dependencies between them come on top.
- The number of data types
- Products, attributes, media, prices, stock, orders and customers are separate contracts, separate mappings and separate test scenarios.
- The direction of the data flow
- A one-way exchange is simpler than a two-way one: with two directions, conflicts have to be resolved and one system has to win when the values disagree.
- Synchronisation frequency
- An overnight batch costs less than an update measured in minutes. A shorter reaction time usually means events, queues and separate handling for pile-ups.
- The quality of the external APIs
- A documented API with filtering and pagination is different work from an export with no versioning, or an interface that cannot say what changed since the last pull.
- Data transformations
- Converting units, merging fields, splitting free-text values and mapping dictionaries. The further apart the two models are, the more rules there are to write and test.
- Business rules
- Publication conditions, exceptions per market, data scopes per channel and decisions of the “what we do not send” kind. Those, rather than the connection itself, usually take the most time.
- Queues
- At higher volumes the flow needs queueing, control over concurrency and resilience to a batch that was only partly processed.
- Error handling
- Validation, processing statuses, retries, discrepancy reports and the decision about what happens to a record that cannot be processed.
- Integration monitoring
- Alerts, visibility of the synchronisation state for the client's team and a way to check that the flow is working — without it, a failure only surfaces as a product missing from a channel.
We confirm the implementation estimate after reviewing the interfaces and sample data — anything earlier would rest on assumptions about someone else's systems. Ongoing care for connections that already run is described by Pimcore maintenance.
FAQ — Pimcore integrations
These answers should help you assess the scope, the systems, the timeline and how the integration is handled.
Let's discuss a Pimcore integrationYes, and it is the most common connection in this kind of project. The ERP usually remains the source of indexes, core data and often prices and stock; Pimcore takes over descriptions, attributes, relations, translations and media. How the connection is built depends on what the specific ERP exposes — an API, a file export or direct database access. The full list of systems is in the section on systems in the architecture.
Yes. Pimcore passes products, categories, attributes, media and translations, and Magento 2 stays responsible for presenting the offer and running the sale. Orders and selected customer data can flow back to the operational systems. The split of responsibility is in the section on integrating with Magento 2 and Shopify, and the platform itself in Magento 2 services.
Yes, with the same split of responsibility as on Magento 2. The difference is the platform's data model: Shopify accepts a narrower range of fields and handles variants and markets differently, so the channel data scope is set around what it can take. The details are in the section on integrating with Magento 2 and Shopify and in Shopify services.
Yes. The platform exposes an API for objects and assets, and Datahub makes it possible to build your own GraphQL endpoints for a specific recipient. In practice one project uses several mechanisms at once — they are described in the section on Datahub and APIs.
It is Pimcore's tool for exposing data outwards: it lets you define GraphQL endpoints, choose which classes, fields and relations are visible in them, and grant each one its own permissions. That way every recipient can get its own scope of data without a separate export being written. Datahub is not the only route, though — some integrations are delivered as custom connectors, imports or queue-based flows.
Usually what we mean is event-driven synchronisation: a change in Pimcore triggers a notification or a job, and the channel receives the data within seconds or minutes. Full real time is rarely needed and can be expensive — at higher volumes you have to queue anyway, so that one mass change does not block everything else. Prices and stock, which have to be current at the moment of purchase, more often flow from the ERP or WMS straight to the store, bypassing Pimcore.
Yes, and it is a typical use. Every supplier has its own format, its own field names and its own data quality, so each gets its own mapping and validation rules. We also agree the key that identifies a product and the rule of precedence when two sources give a different value for the same field.
Yes, and that is usually why it is implemented. Every channel gets its own range of fields, translations and media, plus its own definition of completeness — a product ready to publish in one store need not be ready on a marketplace. Separate endpoints or exports make it possible to change the scope for one recipient without touching the others.
That isn't assumed upfront. We first check what the current systems can do, review the documentation and assess data quality. Replacing a system may turn out to be necessary if its limitations block the required flow, but that's a separate decision.
No. The source of each type of data follows the organisation's processes. Prices can stay in ERP, and stock in WMS. Pimcore can be responsible for descriptions, attributes, relations, translations and media.
Yes, this service also covers rebuilding connections that are costly to develop further, whose error handling is insufficient, or whose documentation no longer matches how they actually work. The first step is reviewing the code, the data, the interfaces and the dependencies.
The scope depends on the number of systems, the data structure, the volume, the synchronisation frequency, how much documentation is available and the number of exceptions to handle. All ten factors are set out in the section on the cost of an integration. The implementation estimate should be confirmed after analysing the interfaces and sample data.
The mechanism can include validation, processing statuses, logs, controlled retries, alerts and discrepancy reports. The exact approach depends on the architecture and how important a given flow is to sales.
Data in Pimcore is reached through an API rather than through a shared database: every connection authenticates on its own, and the transport runs over HTTPS. Which systems may read, which may write and to what data is part of the integration's scope, not a default setting.How the credentials are stored, and who manages them once the integration is live, is settled with whoever administers each of the connected systems. Without that, responsibility for access cannot be divided between us, the client and the suppliers of the other systems.
The documentation scope should cover the architecture, data flows, configuration, contracts, mapping, test scenarios and operating procedures. The final list is defined within the project scope.
After the project ends, the connection can be handed over to the client's team or covered by ongoing maintenance. The scope of continued support is settled separately, based on the number of integrations and the required availability. See the scope of Pimcore maintenance.
Let's start with the map of systems and the data that needs to move between them
In the first call we'll go through the current architecture, Pimcore's role, the systems that need connecting and the biggest problems with the data exchange today. Afterwards we'll point to whether the project should start with an integration analysis, implementing a new connection, rebuilding an existing solution, or tidying up Pimcore itself.
A basic list of systems and a short description of the data that needs to move between them is enough for the first call. API documentation or a diagram of the current architecture will help, but neither is required for the first contact.
