Stokly ERP and InRiver
Integration Agency & Consultants
At a certain scale, product ranges become impossible to manage through manual entry. Inconsistent data between InRiver and Stokly ERP leads to missing attributes on sales channels, incorrect stock categories, and delayed market launches. When the PIM and ERP are out of step, teams spend more time fixing SKUs than selling them. We connect these systems to ensure rich product content from InRiver maps correctly to the item master in Stokly, removing the operational drag that prevents rapid range expansion.
Audit and diagnostic for system interoperability
We connect your Stokly ERP and InRiver PIM quickly, ensuring your ERP and PIM work together for efficient operations. Our consulting services are invaluable, with our system audit services providing a thorough review of your tech stack. This enables our consultants and your team to identify and address inefficiencies, helping your Stokly ERP and InRiver PIM integrations run smoothly. By taking action based on our audit insights, you can deliver a reliable, efficient experience to your customers and keep your technology ecosystem performing at its best.
Solution Design
For the Stokly ERP and InRiver pairing, we typically designate InRiver as the master for enriched product content while Stokly remains the source of truth for operational data including inventory levels. A primary design decision involves the synchronisation logic: we often prioritise batch enrichment flows from InRiver to maintain system stability during heavy catalogue updates. The trade-off is a slight lag in detail updates to ensure reliable mapping between InRiver attributes and Stokly item masters. We typically sequence core SKU and attribute mapping first to ensure primary sales channels remain operational. This design ensures finance can rely on Stokly as the financial record, while ecommerce teams work from enriched product data master records in InRiver.
Mapping operational hierarchy and attribute flows
The integration establishes an operational hierarchy: InRiver acts as the master for rich product marketing data, while Stokly ERP remains the authority for core operational data like SKUs and inventory levels. Synchronisation typically follows a sequence where core item records are verified in Stokly before InRiver pushes enriched attributes. This is designed to prevent product data records that lack a corresponding sellable item. We include monitoring at the attribute level to detect when high-level product data in InRiver does not map correctly to the Stokly item master, ensuring data integrity is maintained across your sales channels.
Orchestrating workflows via secure middleware platforms
Leveraging IPaaS with ISO 27001 and SOC 2 and above security accreditations enables secure, efficient delivery of Stokly ERP and InRiver PIM integrations. Stokly ERP and InRiver PIM benefit from automated, reliable data exchange, reducing manual effort and risk. Using an IPaaS platform ensures ERP and PIM systems are connected with robust compliance, supporting business growth while maintaining high security standards.
Detecting data gaps and mapping exceptions
Dashboards often show a successful sync while hiding underlying data gaps, such as missing product attributes or broken asset links between InRiver and Stokly. We go beyond basic status checks by surfacing specific data exceptions: if a product is enriched in InRiver but the corresponding item in Stokly is missing critical operational data, the system flags it. This prevents hidden issues from compounding into failed storefront launches. By detecting these mapping failures early, your team can resolve data completeness issues before they impact channel performance or stock accuracy measurements.
Operational handover for catalogue management teams
Handover focuses on the ecommerce and operations teams who manage the product lifecycle between InRiver and Stokly ERP. We provide the operating model in plain text, ensuring teams understand that InRiver masters the rich content while Stokly owns the sellable SKU and stock level. Training covers routine checks of the integration layer to catch attribute mapping errors and the process for new product launches. Documentation is delivered as an operational manual rather than a technical archive, detailing who owns exceptions when a data update fails to synchronise. This ensures your team can independently manage the data flow and maintain catalogue integrity across both platforms.
Ongoing monitoring for drift and failures
Post-launch, we provide ongoing monitoring to ensure the Stokly and InRiver sync remains stable. We handle the technical escalation of mapping failures and connectivity issues, but also monitor for data drift. If a change in your product data structure breaks the outbound flow to Stokly, our team identifies the exception before it impacts your sales channels. We take ownership of the technical health of the integration so your team can focus on product enrichment and order fulfilment tasks.
Common failures
Uncontrolled SKU modifications breaking the data link
Operational impact: If a SKU is modified directly in Stokly ERP after the initial sync from InRiver, the system link breaks and that item becomes an orphan. Subsequent product updates from InRiver will fail, leading to incorrect item data, while stock adjustments in Stokly may not feed back to the correct sales channel listings, causing inventory count errors and overselling.
Prevention / Action: Establish the SKU as an immutable identifier once created. The integration's source-of-truth rules must dictate that InRiver owns the initial SKU creation and Stokly ERP owns inventory levels for that SKU. For subsequent updates, the integration should use a permanent internal entity ID from InRiver to update the correct Stokly item record, rather than relying on the SKU as the sole matching key.
Attribute mapping failure for core operational data
Operational impact: When key operational fields from InRiver (like 'country of origin' or 'commodity code') fail to map correctly to Stokly's item master fields, the sync process can fail or create incomplete records. This forces the fulfilment team to manually find information before dispatch, delaying shipments. It can also cause incorrect data on customs forms, leading to seized shipments and financial penalties which the finance team must then reconcile.
Prevention / Action: The integration project must begin with a rigorous data mapping exercise between InRiver schema and Stokly item master fields. Implement transformation logic within the integration layer to correctly format data, for example, converting InRiver's controlled vocabulary lists (CVLs) into the specific values Stokly's fields require. Any item failing validation should be quarantined and an exception report sent to the responsible data team rather than creating a partial record in the ERP.
Archived or unpublished products remaining sellable
Operational impact: When a product is unpublished or deleted in InRiver, the integration often fails to update the corresponding item record in Stokly ERP. This leaves a 'ghost' item active in the ERP, potentially with available stock, which remains sellable on connected channels. The customer service team is left to manage the fallout, cancelling Sales Orders for items that no longer exist and damaging customer trust.
Prevention / Action: Design the integration to handle the complete product lifecycle, including deletion and archival events. When a product status changes to 'unpublished' in InRiver, the integration logic must trigger a corresponding change in Stokly, such as setting the item record to 'inactive'. Schedule a recurring audit process that compares active items in Stokly against the active catalogue in InRiver to catch and disable any discrepancies.
Incomplete weight or dimension data halting dispatch
Operational impact: Stokly ERP often relies on complete weight and dimension data on the item record to integrate with shipping carriers and calculate costs. If this data is missing or incomplete in InRiver, the sync will create an unusable item record in Stokly. This blocks the fulfilment process, as shipping labels cannot be generated, forcing the warehouse team to halt the pick-pack-dispatch workflow and manually investigate, which degrades operational capacity.
Prevention / Action: Enforce data quality at the source by making logistical fields mandatory in InRiver before a product can be published to the Stokly integration channel. The integration itself should have a final validation step; if weight or dimension fields are null, the record should be rejected and flagged in an error queue for the merchandising team to correct in InRiver. Do not allow deficient product data to enter the operational environment.
Frequently asked questions
Which system is the master for product data, InRiver or Stokly ERP?
InRiver is the master for all rich product data, including marketing descriptions, specifications, and digital assets. That information is then synchronised to Stokly ERP to create the core item record. Stokly ERP then acts as the master for all operational data, such as live inventory levels, cost price, and processing sales orders.
How do we prevent SKU mismatches between InRiver and Stokly ERP from breaking the link?
The most effective operating model involves locking the SKU field in both systems after the initial synchronisation from InRiver to Stokly ERP. Manually changing a SKU directly in Stokly ERP after creation will break the link to the InRiver entity. This causes subsequent price and content updates to fail, creating data orphans and leading to inaccurate item records.
What happens if we delete or un-publish a product in InRiver?
Simply deleting an entity in InRiver will not automatically remove the corresponding item record from Stokly ERP, creating a risk of selling discontinued items. The integration must be configured to handle this action, typically by setting the SKU to 'inactive' in Stokly ERP. This prevents new sales orders from being created for products no longer managed centrally from InRiver.
How does the integration stop incomplete InRiver data causing Stokly ERP errors?
The integration uses validation rules to ensure data is complete before creating or updating an item record in Stokly ERP. For example, you can prevent a SKU from synchronising if a critical field like 'cost price' or 'weight' is empty in InRiver. This prevents downstream fulfilment or financial reconciliation issues by ensuring only transactable items exist in Stokly ERP.
We are delaying product launches due to data issues, how does this integration help?
By centralising product enrichment in InRiver and automating the creation of item records in Stokly ERP, you remove the manual processes that cause delays. Once a product is approved in InRiver, the SKU and its attributes are automatically populated in Stokly ERP, making it immediately available for sales orders. This directly connects the product enrichment lifecycle to the order-to-cash process, shortening the time to market.