Skip to main content
Talk to an expert
inriver logo

inriver integration for ecommerce product data

Governed product data published to every commerce channel cleanly. inriver centralises attributes, images and copy in one governed hub, enforces completeness before publishing, and delivers catalogue data to your storefronts and marketplaces in the exact format each one expects. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: product data connector, plugin, extension, workflow.

inriveriWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a inriver integration gives you.

Product teams move faster

Merchandisers no longer wait for manual catalogue updates or email coordination. Attributes, images and relationships flow to all channels as soon as they are approved in inriver.

Channel content consistency

Every storefront and marketplace receives the same product taxonomy, translation set and image assets unless explicitly overridden. Customers see consistent product information across all touchpoints.

Approval bottlenecks dissolve

Workflow automation ensures incomplete products do not reach staging, and blocked items are flagged immediately to the responsible team member instead of sitting in a shared inbox.

Localisation scales without rework

Product descriptions, keywords and metadata are translated once and published to every locale-specific storefront or marketplace channel in a single operation.

Asset management becomes auditable

Product images, documents and downloads are versioned, assigned to channels, and tracked through their lifecycle so you know which asset belongs to which product and which channels have the latest copy.

Catalogue migrations become repeatable

New storefronts or marketplace channels inherit the same product attributes, families and completeness standards, so onboarding a channel takes days not months.

02 · When it's worth it

Where a inriver integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Centralise product attributes and variant data from multiple sources into a single source of truth
Enforce completeness rules and approval workflows before catalogue content reaches storefronts
Manage product images, documents and digital assets with version control and channel-specific sizing
Syndicate product data to Adobe Commerce, Shopify, BigCommerce and marketplace channels with channel-specific field overrides
Translate product descriptions, keywords and metadata into multiple languages with localisation audit trails
Define and maintain product hierarchies, families and relationships for navigation and search
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

No stock or live pricing visibility in PIM

inriver holds product attributes, families and relationships but does not manage inventory levels or real-time pricing. Stock and pricing sync from your ERP or pricing engine separately, creating a dependency on parallel integration pipelines.

Limited built-in ecommerce platform connectors

inriver ships with pre-built links to major platforms but Other storefronts, headless deployments or regional marketplaces may require manual export or middleware to consume catalogue feeds in the right format.

Taxonomy and variant model governance in isolation

inriver excels at managing category trees and variant options but does not enforce how variants map to SKU structures in your ERP or OMS. Cross-system variant alignment and deduplication must be owned separately.

Translation workflow without multi-language reconciliation

inriver supports translation of product copy but does not prevent conflicting translations across languages or detect when a source language attribute changes after localisation is complete.

Channel-specific fields without shared governance

Each channel can have unique required fields and content rules, but inriver does not prevent drift or conflicting rules if multiple teams maintain channel configurations separately.

04 · The real work

Product data governance often splits across teams and systems until a PIM enforces who owns what and ensures completeness before anything reaches a storefront.

05 · Where it sits

Where this integration sits in your estate.

inriver holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

Built for your platform, not a specific one. inriver integrates with any ecommerce core through the same contract.

System of record
Source / owner
inriver
System of record for product data governance
  • Product attributes and enrichment
  • Product families and hierarchies
  • Variant configuration and options
  • Product copy, descriptions and metadata
  • Product images and digital assets
  • Completeness rules and data quality gates
  • Approval workflows and role-based access
  • Channel-specific product readiness status
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Storefront product page rendering
  • Category navigation and site search
  • Product discovery and merchandising rules
  • Add-to-cart and checkout experience
  • Customer reviews and ratings
Connected neighbours
Integration layer
ERP
Provides base product codes, supplier information and upstream attribute source; inriver enriches and publishes attributes back
Integration layer
Stock and OMS
Manages inventory levels and fulfilment; inriver publishes product structure but stock sync flows separately
Integration layer
Search and merchandising
Indexes product attributes and attributes from inriver to power facets, synonyms and search ranking
Integration layer
Marketplace connectors
inriver exports product data to marketplaces; marketplace feeds may send sales or feedback back for enrichment
Integration layer
BI and analytics
Consumes product catalogue extracts from inriver for reporting on completeness, asset coverage and channel readiness
Integration layer
Digital asset management
inriver may integrate with DAM platforms to pull master images or push channel-specific variants for storage
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • ERP (SAP, NetSuite, Sage)
  • OMS / order management
  • Search and merchandising platform
  • Marketing and CDP
  • Marketplace connectors (Amazon, eBay)
  • WMS / warehouse management
  • Analytics and BI platform
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into INRIVER
←From INRIVER
↔BOTH WAYS
Upstream product feeds: Product data arrives from ERP systems, supplier feeds, internal spreadsheets or manual entry into inriver attributes and families
Duplicates are identified and merged; relationships are enriched.
Asset uploads and transformations: Product images, PDFs and downloadable documents are uploaded or imported via URL feeds, tagged with asset family and channel assignment, then automatically resized or cropped for each destination channel.
Channel-ready catalogue exports: Governed product data flows from inriver into your commerce platforms and marketplaces as CSV, XML, API call or real-time feed, with channel-specific required fields, translations and asset links applied.
Completeness and workflow signals: Product owners mark items complete, submit for approval, and receive feedback from merchandisers or channel teams
Blocked items, missing images and failed rules feed back into the workflow queue for remediation.
Syndication readiness status: Channel readiness flags and attribute coverage reports stream out to BI platforms or commerce dashboards so merchandisers can see which products are ready to publish and which need editorial attention.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Design the product data estate

    We map your attribute model, family hierarchies and variant logic in inriver; link it to your ERP and supplier feeds upstream; and design channel-specific export mappings downstream so every system speaks the same product language.

  2. 02
    Build owned workflows and approvals

    We configure inriver approval steps, completeness rules and role-based access so product owners, merchandisers and channel teams each see only what they need to action, and bottlenecks are visible in real time.

  3. 03
    Integrate inriver with commerce platforms

    We build the API bridges, CSV feeds or middleware connectors that push governed product data from inriver to Adobe Commerce, Magento Open Source, Shopify, BigCommerce and other storefronts on a schedule you define.

  4. 04
    Set up asset pipelines and transformations

    We configure image resizing, CDN assignment, watermarking and channel-specific asset rules so merchandisers upload once and every channel receives the right size, format and version automatically.

  5. 05
    Provide observability and support

    We monitor feed success rates, flag unshipped products or broken asset links, and create dashboards so you know the health of your catalogue in real time. We stay on call for changes and troubleshooting.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataProduct attributes
Source / ownerinriver
Maintained byProduct teams, suppliers, inriver admins
NotesSource data arrives from ERP or supplier feeds; inriver enriches and governs; storefronts consume the published version.
DataProduct families and hierarchies
Source / ownerinriver
Maintained byMerchandisers, category owners
Notesinriver maintains the product tree and relationship rules; navigation and faceting in storefronts inherit the structure.
DataVariant model and configuration
Source / ownerinriver
Maintained byProduct teams, variant governance owners
Notesinriver defines variant options and bundles; ERP validates SKU mappings separately to ensure stock alignment.
DataProduct descriptions, editorial copy and metadata
Source / ownerinriver
Maintained byContent teams, SEO specialists, copywriters
NotesAll copy is authored and versioned in inriver; channel-specific overrides are stored but not synced back upstream.
DataProduct images and digital assets
Source / ownerinriver
Maintained byAsset managers, brand teams
Notesinriver stores master assets and channel assignments; CDN or cloud storage hosts the actual files; resizing rules are inriver-configured.
DataCategory taxonomy and classification
Source / ownerinriver
Maintained byTaxonomy owners, merchandisers
Notesinriver is the authority for product classification; search and marketplace feeds consume the published taxonomy.
DataCompleteness rules and approval workflow
Source / ownerinriver
Maintained byPIM admins, product operations
Notesinriver enforces which fields must be filled and who must approve before publishing; other systems do not override or bypass these gates.
10 · Experienced integrator

Built product data estates before

iWeb has built inriver integrations across multi-channel estates where product data must stay consistent, complete and compliant across Adobe Commerce, Shopify, BigCommerce and marketplaces. We understand how inriver sits alongside ERP, OMS, search and asset management.

We design attribute models, family hierarchies and variant configuration in inriver to align with your ERP's SKU structure and your storefronts' content requirements.
We build approval workflows so product teams, merchandisers and channel owners know what is blocking a product and who must unblock it.
We integrate inriver feeds into multiple storefronts, marketplaces and headless commerce deployments, transforming inriver's export format into each system's expected schema.
We set up asset pipelines so product images and documents flow from inriver through CDN or cloud storage to storefronts with channel-specific sizing and format applied.
We monitor inriver feed health and provide dashboards that flag stale product data, failed exports, incomplete products and broken approval queues.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify completeness rules block incomplete products and allow only fully ready products to export.
Confirm product attributes export to each connected storefront with correct channel-specific field overrides applied.
Test variant combinations export with matching SKU references so storefronts do not list variants with zero stock.
Validate image assets are resized and delivered in the correct format for each channel's expectations.
Check approval workflows route to the right owner and prevent bypass when a required sign-off is missing.
Confirm translations are exported together with source language and missing language variants are flagged.
Test rollback: revert a product attribute and confirm the older version is not re-published until re-approved.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Attribute sync lag between inriver and ERP

If ERP attributes are updated outside inriver (e.g. supplier-managed SKU properties), inriver may show stale values until the next batch sync runs. Manual re-sync or duplicate-detection rules prevent conflicts.

Channel-specific required fields create orphaned products

When a new channel is added with stricter field requirements, existing products fail the completeness gate and are held from publishing. If product teams are unaware of the new rule, inventory goes unlisted for days.

Variant explosion without SKU alignment

inriver allows infinite variant combinations but does not validate them against your ERP's SKU master or OMS stock keeping structure. Storefronts publish variants with no matching stock, causing backorder surprises.

Image asset versioning breaks older exports

When a product image is replaced in inriver, storefronts that do not re-import the catalogue feed may display outdated images indefinitely. API-driven systems consume the latest asset link but CSV imports do not auto-refresh.

Translation completion goes unseen

inriver tracks whether a language variant exists but does not alert product teams if a translation is missing or incomplete. Channels that require full localisation publish with blank or machine-generated text.

Marketplace field overrides silently drift

If individual channels override inriver attributes (e.g. a different product title for Amazon vs. Shopify), those overrides live outside inriver and are not synced back. Future catalogue updates miss channel-specific data, creating inconsistency.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about inriver integrations.

How do we define which product attributes must be filled before a product is ready to publish?

inriver's completeness rules let you specify mandatory fields, image counts, translation requirements and approval steps per family or channel. Products that fail the rule are flagged and held from export until remediated.

Can we maintain different required fields for different channels or marketplaces?

Yes. inriver allows channel-specific completeness profiles so Amazon, Shopify and your own storefront can each have unique mandatory field lists. A product must satisfy all rules for the channels it is assigned to before it can be marked ready.

How do product images and digital assets sync to our storefronts?

inriver stores the master asset library and applies channel-specific sizing, cropping and format rules. Images are exported via API or feed alongside the product catalogue, and your storefront pulls them from the CDN URL provided by inriver.

What happens when we need to translate product copy into new languages?

Translators request translations in inriver, complete them in the inriver interface, and mark the language variant done. Completeness rules can require translations for a product to be ready. All language versions are exported together to storefronts.

How does inriver know what products are actually in stock or available for sale?

inriver does not manage stock levels; that data lives in your ERP or OMS. You sync stock into your storefronts separately from inriver's product attributes. Both flows must align so storefronts show the right attributes for the inventory they hold.

Can we override inriver product data on a per-marketplace basis without changing the central record?

Yes. inriver supports channel-specific field overrides so you can publish a different title or description to Amazon without modifying the master product in inriver. However, overrides are not synced back, so future inriver updates may not reflect them.

How do we know when a product is ready to publish to all channels?

inriver marks products as channel-ready when all completeness rules, translations and approvals for that channel are done. Channel readiness dashboards show which products are blocked and why. You can export only ready products or flag unready ones for team attention.

What happens if we add a new ecommerce platform or marketplace?

You configure the new channel in inriver with its required fields, asset sizes and language rules. Existing products are re-evaluated against the new completeness gate. Products that fail the new rules are flagged; those that pass are exported in the format your new platform expects.

How do variant combinations work in inriver, and how do they map to SKUs in our ERP?

inriver lets you define variant options (e.g. size, colour) and generate combinations. Each combination can have its own attributes, images and SKU reference. Your ERP must validate that every inriver variant combination has a matching stock-keepable SKU, or products with missing SKUs should not be exported.

Can different teams own different parts of the product data (one team owns descriptions, another owns images)?

Yes. inriver supports role-based access and approval workflows so content teams, asset managers and product ops each have visibility into their area. Approval steps can require sign-off from multiple teams before a product is marked ready.

How do we prevent stale product data from reaching our storefronts after an update?

inriver tracks versioning and audit trails. You can export only products that have been updated since the last sync, or you can trigger a full re-export on a schedule. Storefronts that pull via API see the latest version; CSV-based storefronts need a re-import to pick up updates.

What happens if a product attribute changes after it has already been translated?

inriver does not automatically flag translations as stale when a source attribute changes. You must use audit reports or manual review to find attributes that changed since translation was completed, and re-queue those items for translator review.

How is product data exported to storefronts that do not have a pre-built inriver connector?

You can export via CSV, XML, or JSON feed and load it into your storefront or middleware via FTP, SFTP, API or webhook. iWeb can help design the export mapping so inriver's attribute names and values transform into your storefront's expected schema.

Can we bulk-import product data from a spreadsheet or legacy system into inriver?

Yes. inriver supports bulk import via CSV or API. We help map your legacy data structure to inriver attributes and handle deduplication, family assignment and enrichment so imported products are clean and ready for governance.

Next step

Have a inriver integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →