Magento Salsify: Bring Product Data From the PIM Reliably Into the Shop

Salsify keeps product data centrally: articles with their attributes, relationships, media and language versions. The PIM is the source for everything a customer reads and sees about a product, while prices and stock usually come from an ERP. A shop is one of several channels fed from the PIM.

For Magento Salsify that means: product data goes from Salsify into the shop, usually only in this direction. Articles released in the PIM with descriptions, attributes, images and translations are created or updated in Magento as products. The advantage is obvious: your editorial team maintains data once, and every channel receives the same state.

The data model of Salsify is set up per business with properties and assignments. Two businesses with Salsify therefore often look very different: other properties, other groups, other relationships. Magento Salsify therefore always begins with the question how your model is built and which parts of it are needed in the shop.

Prices, stock and orders usually do not belong in the PIM. We clarify in the inventory which data comes from which system so that the shop does not have contradicting sources.

Another point is the release process. In Salsify products are usually reviewed and released for channels. Magento Salsify takes over only released articles so that unfinished texts never appear in the shop. What these states are called and what they mean we clarify with your editorial team, because it determines when an article becomes visible in the shop.

Which data flows in Magento Salsify you define with us in the inventory. Typically there are five areas.

Not every Magento Salsify project needs all five areas. Often it begins with orders and stock and later grows by article maintenance and documents. This way you see results quickly and can use the budget in stages.

The table shows a typical pattern. In your business it may differ, and that is exactly what we clarify in the inventory.

With Magento Salsify a clear rule on data ownership prevents most disputes. Whatever can be changed in both systems leads to contradictions sooner or later. That is why we define exactly one leading system per type of data and describe the rule for the conflict case. Especially with variants, units and tax rates an assignment table that the department and the developers review together is worthwhile.

For Magento Salsify, Salsify offers according to the information we found a REST interface that is described in the developer portal of the vendor. It covers products, properties, digital media as well as imports and exports, the login runs through an API token or through OAuth 2.0. Exports are started through so-called export runs. On request limits we found no reliable information, so we plan bulk comparisons considerately and clarify them beforehand.

According to a press release from 2021 the vendor presented an own connector for Adobe Commerce and Magento Open Source that was created together with an Adobe partner. We did not find an official description of its current state, and there are also solutions from third-party vendors. Whether and how far the connector covers your model we check before the quote and tell you openly if it is enough.

For Magento Salsify the same holds as for every integration: the interface is only half of the work. The other half is the mapping: which field becomes which attribute, which entity becomes which product type, which language becomes which store view. We keep this mapping in the admin as settings so that it can be changed without development.

For the connection of Salsify and Magento there is a connector of the vendor whose current state we check as well as solutions from third-party vendors. Whether one of them fits your model we check honestly before a decision. If an existing connector covers your requirements, it is often the more economical choice, and we will tell you so.

An individual development for Magento Salsify pays off if your data model deviates from the usual: own entities, complex relationships, special rules for variants or several shops with different ranges. It is more expensive at the start but fits exactly. Include the care as well: a ready-made product saves development time but causes license and update costs, and an individual development needs someone who looks after it.

A middleware pays off if more than two systems are connected, for example PIM, ERP, shop and marketplaces. The decision aid is in the guide to ERP integration.

On the Magento side we build the integration as its own module according to the standards of the system, without interventions in the core. The module uses the interfaces and queues of Magento so that transfers run in the background and the shop does not become slower for visitors. Orders are placed in a queue on arrival and processed there until the ERP has confirmed them.

Prices by customer group, tier prices and several warehouses are mapped by Magento with its own functions that the integration fills. Where possible we use these standard functions instead of inventing our own tables. That keeps the shop update-capable and lets other developers join in later.

In the admin you see what was transferred: a log shows date, record and result, with a filter for errors. For the peculiarities of Salsify we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With Salsify the focus is often on product content that is delivered to many recipients: own shops, retailers and marketplaces. Magento Salsify therefore begins with the question which data the own shop receives and which is meant only for other channels.

We see these points again and again in projects. They can be planned if they are known early.

• Properties and groups

  The properties in the PIM do not fit the attributes and attribute sets of Magento one to one and need a clean assignment.

• Variants

  The variants in the PIM are formed differently than in Magento and lead to duplicate or missing products.

• Media

  Large images and many documents prolong the import and overload the transfer.

• Unclear data ownership

  Texts are changed in the PIM and in the shop and overwrite each other.

• Missing monitoring

  A failed import is noticed only after days because nobody looks at the log.

• Languages

  Missing translations lead to empty fields in individual store views.

An integration connects two systems with business data, so clear rules apply. The exchange runs encrypted, credentials do not lie in the source code but in the protected configuration, and the integration receives only the rights it needs. Access belongs to a separate service account, never to a private account of a person.

When testing we work with test data or anonymized data as far as possible. As soon as developers get access to personal data, for example customer accounts or orders from Salsify, an agreement on commissioned data processing is needed. We clarify that before the start so that you are legally well set up.

The log of the integration contains what is necessary for operation but no credentials and no unnecessary personal data. Retention periods are defined with you. These notes are not legal advice, the concrete arrangement depends on your company.

We keep the start deliberately short so that you quickly know whether and how the integration is feasible.

The following constellations are examples from the practice of Magento Salsify projects, not statements about particular customers. The first is a manufacturer with thousands of articles that are maintained in several languages and for several channels. The PIM is the only source for product texts, and the shop must not overwrite them.

The second constellation is a merchant with many variants and own relationships in the PIM. The challenge lies in mapping variants and accessories cleanly in Magento and keeping the order of the images. We define early what stays in the PIM and what arises in the shop.

The third constellation is a business that switches from another shop system to Magento and keeps Salsify. Here the existing connection is the benchmark: what it achieves today the new shop should at least achieve. How the switch itself runs is described on our page on migration.

In all three constellations a delta comparison proves itself with Magento Salsify: only articles that changed since the last run are transferred. That shortens the run time, spares the shop and makes errors easier to find. A first full run with a small part of the range serves as a test before all articles follow.

An interface is not a one-off project but ongoing operation. After the start a log monitors every transfer: what was transferred when, what failed, what is repeated? Errors that cannot be fixed automatically are reported visibly so that nobody learns of them only through a customer complaint.

Updates change the situation. A Magento update, a new state at Salsify or a change of the vendor interface can affect the integration. Therefore the planning includes an agreement on how updates are tested and who approves them. Ongoing care can be regulated through a maintenance contract that covers monitoring, updates and error fixing.

Documentation is part of the delivery. You receive a description of the data flows, the assignments and the rules for special cases so that your team or another provider understands the integration and can continue it. Source code and access stay with you.

A flat figure for Magento Salsify would be unreliable because the effort depends on your constellation. It is determined by the number of data flows, the quality of the data in Salsify, the number of special cases with attributes, variants, media and languages and the required timeliness. A data flow in one direction is built much faster than a synchronization in both directions with conflict rules.

We work with an open hourly rate of 30 euros net, without emergency surcharge. After the inventory you receive a written estimate that lists the data flows individually so that you can control scope and order yourself. For clearly defined packages a fixed price is also possible. All prices are on the page pricing.

Besides the development, include the running items: hosting, maintenance and, where applicable, licenses or fees for Salsify and for additional services. We show these items separately in the estimate so that you can compare quotes over several years.

An honest offer includes naming the limits. We do not sell a ready-made connector off the shelf but develop Magento Salsify project by project according to your processes. That means: we implement exactly what you need, but not in a day and not for a flat price that cannot be calculated beforehand.

We are a web agency in which fixed freelancers work together, all from home offices. We are not a large agency with a hundred employees and cannot take on every project at every time. We tell you early whether and when we have capacity. We name customers only with their consent, and in the first conversation we gladly talk about comparable constellations.

We give no legal advice. Questions about commissioned data processing, data protection and the license terms of Salsify you clarify with your legal adviser and the vendor. What is technically possible depends on version, operation and license of your system and is checked in the inventory.