Cin7 Core and InRiver
Integration Agency & Consultants
Operational drag begins when a brand's product complexity exceeds the flat structure of an ERP. In high-volume environments, managing multi-language descriptions, technical specifications, and digital assets inside Cin7 Core SKU records creates a bottleneck for marketing and product teams. Connecting InRiver separates the product story from inventory logic, allowing marketing to fast-track catalogue enrichment while operations focuses on stock accuracy and order fulfilment. This integration is designed for teams where manual product data entry is no longer a viable way to launch across multiple channels.
Mapping ownership boundaries and data structures
Before technical work begins, we diagnose the ownership boundaries between marketing and operations. For a Cin7 Core and InRiver integration, discovery focuses on mapping product specifications. We identify where attribute differences between InRiver’s modelling and Cin7’s data structure might cause sync errors. We determine which system owns specific SKU metadata and how digital assets are managed within the ERP records. Resolving these logic gaps early helps avoid launching products with incomplete information. This process ensures the team can move from manual data entry to a more automated enrichment workflow.
Solution Design
In the Cin7 Core and InRiver architecture, we establish InRiver as the master for all enriched product data. Our design prioritises catalogue stability by pushing finalised specifications to Cin7 Core to create or update SKU records, ensuring the ERP logic remains focused on inventory and orders. A key decision involves mapping InRiver relationships, like shop-the-look groups, into Cin7’s Bill of Materials or custom field structures. We typically choose to batch these catalogue updates rather than using real-time triggers. While this introduces a minor lag for intra-day changes, it prevents API rate limiting and ensures data integrity for complex attributes. This architecture settles the ownership boundary: marketing owns the product story in InRiver, while finance and ops rely on Cin7 Core as the source of truth for stock valuation and fulfilment.
Connecting enriched attributes to item records
This integration establishes InRiver as the authority for enriched product data. Once a product is finalised in the PIM, the integration pushes SKU data and technical attributes to Cin7 Core to create or update item records. We apply mapping rules that translate InRiver's complex product relationships into the structure Cin7 Core requires for inventory management. This process helps prevent SKU errors and protects the ERP from complex data overhead. Monitoring is embedded to identify attribute mismatches or sync failures, ensuring that SKU records remain accurate for warehouse and fulfilment operations. This sequence stops incomplete product data from reaching sales channels.
Orchestrating complex product data transformations
We evaluate the need for middleware based on the complexity of your product data and the volume of SKU updates. In many Cin7 Core and InRiver setups, an integration layer is used to transform InRiver’s product modelling into the specific format required by Cin7. This helps manage multi-language descriptions and media assets more effectively than a direct sync. While a direct connection might suit simple catalogues, an integration layer provides better visibility into data issues before they reach the ERP. This ensures that only valid, enriched product data reaches the operational inventory system.
Surfacing synchronisation exceptions and attribute failures
Dashboards alone often mask the data issues that degrade a catalogue over time. High-level charts rarely signal when high-resolution media fails to attach or when technical specifications exceed Cin7 Core field limits. These hidden issues compound, leading to truncated product descriptions and inconsistent channel data. Visibility in this integration means surfacing synchronisation exceptions at the attribute level. By identifying specific mapping failures early, teams can correct the source data in InRiver before it affects sales channel performance or customer trust. This focus on operational intelligence ensures that data gaps are caught before they create order-to-cash friction.
Handover for marketing and operations teams
Marketing and operations teams adopt the new operating model by taking ownership of the enriched product lifecycle. Marketing teams manage complex data modelling in InRiver, while operations monitors SKU creation and stock logic in Cin7 Core. We hand over the daily and weekly checks required to maintain catalogue integrity, including how to read alerts from the integration layer and who owns specific exception types. Training is anchored in the design decisions made for your workflow, ensuring finance and ecommerce teams understand how data flows into sales channels. Our operational documentation is written for the people running the business. It serves as a practical guide for product launches and data hygiene rather than a technical archive.
Managing catalogue stability and data health
Ongoing support focuses on operational stability rather than technical maintenance. We monitor the integration for attribute mismatches, sync failures, and media errors that standard ERP dashboards often miss. When exceptions occur, context is provided to help marketing or operations teams resolve the issue at the source. This includes established escalation paths for mapping errors and regular reviews of data health. As your product catalogue evolves in InRiver, we ensure the sync to Cin7 Core remains reliable and does not become a manual burden.
Common failures
Attribute truncation and mapping mismatch
Operational impact: InRiver often holds technical specifications and multi-value attributes that Cin7 Core cannot natively accept. When the integration attempts to force these into a flat ERP record, data is either truncated or causes a sync failure. This blocks new SKU creation, leaving merchandising teams unable to launch products while operations waits for valid item records to begin receiving stock.
Prevention / Action: Map complex InRiver attributes to Cin7 Core custom fields or the Bill of Materials structure before development. A transformation layer handles the flattening of InRiver data, ensuring required fields are populated while exceptions are flagged for manual review rather than failing the entire sync.
API rate limiting during peak catalogue updates
Operational impact: Seasonal launches often involve pushing hundreds of product updates from InRiver simultaneously. These high-volume bursts can exceed Cin7 Core's API limits, leading to partial syncs where some SKUs update and others do not. This creates a sync illusion where the catalogue appears updated, but pricing or descriptions vary across channels, forcing manual reconciliation.
Prevention / Action: Implement a throttled queuing system that batches updates based on API availability. Critical data, such as price or SKU status, is prioritised over descriptive marketing copy. Automated retries handle transient failures without requiring merchant intervention.
Source-of-truth ambiguity for discontinued products
Operational impact: When InRiver archives a product, the status change may not propagate to Cin7 Core. This leaves obsolete SKUs active in the ERP, leading to "ghost stock" appearing in procurement reports or accidental inclusions in manufacturing runs. Finance then struggles with inaccurate inventory valuations due to active records for dead stock.
Prevention / Action: Establish a hard ownership boundary where an archival event in InRiver triggers an 'Inactive' status in Cin7 Core. This prevents the SKU from being used in new transactions while maintaining the historical record for financial reporting.
Frequently asked questions
If InRiver is our product master, how do new SKUs get into Cin7 Core?
The standard operating model uses InRiver for all product enrichment, from marketing copy to technical specifications and digital assets. Once a product is approved in InRiver, the integration creates or updates the corresponding item record in Cin7 Core with all essential data. This ensures Cin7 Core has accurate SKU data for inventory and order management without manual re-entry.
We spend weeks preparing product data in spreadsheets to load into Cin7 Core. How does this integration help?
This is a primary commercial trigger for integrating InRiver. Instead of using spreadsheets, your merchandising teams work in InRiver's collaborative environment to enrich product data and assets. The integration then automates the creation of item records in Cin7 Core, replacing slow, manual data entry and significantly shortening the time to market for new collections.
Our products have complex specifications. Will we lose this detail when syncing from InRiver to Cin7 Core?
This is a common concern because Cin7 Core's item record has a simpler data structure than InRiver. A well-designed integration maps essential operational data like SKU and price directly. More complex specifications, like technical attributes or designer notes, can be mapped to custom fields in Cin7 Core so the data is not lost, preserving the rich detail from InRiver within the ERP.
What happens if we unpublish or delete a product in InRiver? Does the item record also get deleted in Cin7 Core?
This does not, and should not, happen automatically, as it could lead to serious data loss in your ERP. When a product is retracted in InRiver, the integration should be configured to mark the Cin7 Core item record as inactive, not delete it. This intentional design choice protects the integrity of any historical sales orders or stock movements associated with that SKU.