A centrally maintained product isn't automatically publishable to every sales channel. Every shop, marketplace, retailer, or data recipient expects its own field names, required attributes, categories, value formats, and sometimes its own content entirely. Product data syndication translates a canonical product record into whatever channel structure each destination needs.
PIMSuite handles that mapping, transformation, and distribution logic.
The canonical product model
Shopify
↑
Amazon ← canonical product → B2B portal
↓
Retail feed
The central catalog shouldn't turn into the union of every downstream schema. Bad: add amazon_bullet_1, amazon_bullet_2, shopify_vendor, partner_x_field_93 directly into the core model, a few more fields for every new channel. Better: maintain a sensible canonical model and map it outward. That's the same principle as the product catalog: the data model follows the products, not the channels.
Three separate mapping problems
What often gets treated as one problem is really three:
1. Field mapping - internal selling_price, channel price.
2. Value transformation - internal 29.99 EUR, channel 2999.
3. Vocabulary mapping - internal size = M, channel medium.
That distinction is why PIMSuite offers three separate mechanisms for this instead of folding everything into one configuration.
Attribute mapping
For each channel, you define how your master attributes map to the channel's field schema. A mapping connects your internal attribute (e.g., selling_price) to the channel's field (e.g., price) with an optional transformation.
Nine built-in transformation types cover the most common cases:
- Uppercase / Lowercase - normalize text case
- Price in cents - convert €29.99 to 2999
- Price with currency - format a price with its currency symbol or code
- Gross to net - strip tax from a gross price
- HTML strip - remove formatting for plain-text fields
- Boolean YN - convert true/false to Y/N
- Boolean 1/0 - convert true/false to 1/0
- CDATA wrap - wrap content for XML feeds
Why this matters: without fixed rules, one person maintains shopify_export.xlsx, another builds amazon_final_v3.csv, a partner wants products.xml - and every product update means rebuilding three files by hand. Transformations should be repeatable rules, not spreadsheet cleanup performed after every export.
Custom formula-based transformations exist today for supplier import mapping, but aren't yet wired into channel export mapping:
Currently available for channel exports: the nine built-in transformation types above.
Roadmap: arbitrary formula-based transformations for channel export mapping too.
Value mapping
Your internal vocabulary and the channel's vocabulary are rarely the same. You might store sizes as "S", "M", "L" while the channel expects "small", "medium", "large". You might store a status as "active" while the channel expects "1".
Value mapping handles this translation per attribute, per channel - without modifying your master data.
Taxonomy
Field schemas are only part of marketplace integration - categories are the other part. An internal path like "Shoes > Running Shoes" rarely lines up directly with a marketplace's category tree, such as "Clothing, Shoes & Jewelry > Men > Athletic > Running" on Amazon, or the Google product taxonomy.
PIMSuite's AI features can propose a matching Google product taxonomy category for each product, which you confirm or override. Taxonomy category can also be used as a condition for channel collections (see below), to control which products belong in which channel. A dedicated mapping table that automatically translates an arbitrary internal taxonomy into an arbitrary channel-specific taxonomy isn't a distinct feature beyond that today.
Rule-based product collections
Not every product belongs in every channel: Brand A can't sell on Amazon, only products above €20 go to Marketplace X, the US store only gets products with English content, the wholesale portal excludes discontinued products, a retail partner only gets its private-label range.
PIMSuite automatically defines which products belong to which channel, based on rule conditions:
- brand, status, product family, taxonomy category
- price range, attribute value
- EAN present/absent
- custom attribute conditions
Combine conditions with AND/OR logic. Products that meet the rules are automatically included in the channel's export set.
Channel selection is not the same as channel readiness
A product can be selected for Amazon without being ready for Amazon:
Selected for Amazon: yes
Ready:
✓ title
✓ price
✓ EAN
✗ required size attribute
✗ marketplace category
The rule-based collections above solve the selection question. Readiness is a different question: does the record satisfy this specific channel's required fields? PIMSuite currently tracks completeness per language across the whole catalog, so you can filter down to what still needs work before exporting. Completeness scoped specifically to an individual channel's required attributes is on the roadmap, not available today.
Channel-specific overrides
Some channels need a different product name or description - not a translation, but a genuinely different positioning. For example:
Canonical title: "Bosch Professional GSR 18V-55 Cordless Drill"
B2B portal: "GSR 18V-55, 18V, bare tool"
Consumer shop: "Bosch Professional GSR 18V-55 cordless drill without battery"
Marketplace with a character limit: "Bosch GSR 18V-55 18V Drill"
Same product, different channel context. PIMSuite supports channel-specific overrides for any text attribute, so you can customize without duplicating your master data. That's separate from language-specific localization - the two can be combined, but there isn't a formally documented precedence model today describing how a canonical value, a localized value, and a channel override rank against each other when more than one could apply at once.
Multi-channel vs. omnichannel
Multi-channel means selling or publishing through several channels. Omnichannel means the customer experience and processes are connected across channels.
A PIM primarily supports the first by supplying consistent product information. It can be infrastructure for the second, but it doesn't automatically make a business omnichannel.
Syndication vs. integration
Syndication transforms product records and distributes them to destinations. Integration is often broader and bidirectional - stock, orders, customers, pricing, status callbacks.
PIMSuite's Shopify sync sits closer to an integration than a static export: it runs on a recurring cycle and keeps Shopify aligned with the PIM record, rather than handing over a file once.
Push, feed, and API
Push - PIMSuite actively sends data to a destination, like Shopify.
Feed/export - the destination periodically reads a file you provide (CSV/XML/JSON).
Pull/API - a partner fetches current product data themselves through the API.
PIMSuite covers all three: Shopify sync as a push-style integration, export files as a feed, and the REST API for pull access.
Full sync vs. delta sync
Instead of re-downloading 100,000 products on every fetch, products:read with delta sync returns only what's changed since a timestamp - say, 87 records instead of 100,000. That cuts traffic, processing, and load on the receiving side substantially, especially with frequent sync cycles.
What a resilient channel connection needs beyond this
If a marketplace rejects 27 of 1,000 products, a system needs to be able to answer: which ones failed? why? retry automatically? does one bad product block the whole export? PIMSuite's export history keeps the five most recent export runs per channel with a timestamp and a "download latest" link - detailed per-product failure feedback, automatic retry, and re-downloading older exports by ID aren't part of the feature today.
Export history as traceability
The genuinely useful question is often: what exactly did we send this retailer yesterday? That's invaluable when someone reports "your feed changed the price." PIMSuite's export history, with timestamp and download link, helps reconstruct the last-sent state, even though a full diff or historical re-download capability for older runs doesn't exist yet.
Marketplace requirements as a contract
A useful mental model: every destination has a data contract.
Required:
title
GTIN
price
category
brand
Conditional:
battery_type if battery_included = true
Allowed:
description <= X characters
The mapping layer is then an adapter between your canonical product model and each channel's contract.
Worked example: one product, four channels
A manufacturer sells through its own Shopify store, Amazon, a B2B distributor feed, and a partner portal. One SKU has one canonical technical record. But:
Shopify needs a marketing title and the full image gallery.
Amazon needs the marketplace category and Amazon-specific bullet points.
Distributor needs a short description, the wholesale price, and a CSV format.
Partner portal needs every technical asset.
This is exactly what attribute mapping, value transformation, channel-specific overrides, and collection rules exist to handle together.
Shopify integration
Shopify sync is built in: map your PIMSuite attributes to Shopify fields, define your collection rules, and publish. Product updates in PIMSuite are reflected in Shopify on the next sync cycle.
Public REST API
For channels not covered by built-in integrations, PIMSuite provides a public REST API with scoped keys:
schema:read- access attribute and family definitionsproducts:read- query product data with delta sync (changes since a timestamp)products:write- create or update products programmatically
API keys support expiration dates for time-limited partner access.
How PIMSuite implements this today
PIMSuite maps a canonical product model onto arbitrary channel schemas through attribute mapping, nine built-in value transformations, and vocabulary mapping. Rule-based collections automatically decide which products belong in which channel; channel-specific overrides allow different positioning without duplicating data. Shopify sync runs as a built-in integration, and additional channels can connect through the REST API with delta sync. What's deliberately still missing today - formula-based channel transformations, channel-specific readiness scoring, detailed export failure feedback - is called out above as roadmap, not quietly assumed.