Brightpearl and InRiver
Integration Agency & Consultants
Manual product creation in Brightpearl becomes a growth bottleneck the moment a brand expands into new territories or high-volume seasonal drops. When InRiver is not tightly coupled with commercial operations, teams lose days to manual SKU entry and attribute mapping. This friction causes launch delays and data inconsistencies that lead to incorrect listings. We build the connection between InRiver and Brightpearl to automate the path from enrichment to sale, ensuring SKU creation is driven by validated product data rather than manual guesswork.
Auditing system gaps and data inefficiencies
We connect Brightpearl and InRiver quickly, ensuring your ERP and PIM platforms work together efficiently. Our consulting services are invaluable, with system audit services that uncover inefficiencies and integration gaps across Brightpearl, InRiver, ERP, and PIM. These audits empower both our consultants and your team to take decisive action, keeping your technology ecosystem running smoothly and efficiently. This enables you to deliver a consistently excellent experience to your customers.
Solution Design
For the Brightpearl and InRiver pairing, we establish InRiver as the master for all enriched marketing data while Brightpearl remains the source of truth for inventory and SKU creation. A primary design decision involves the validation mapping between InRiver's flexible taxonomy and Brightpearl's rigid attribute requirements. We typically sequence product specification flows first, ensuring standard SKUs are validated in InRiver before they attempt to post to Brightpearl. This creates a trade-off: forcing strict data validation slows the early enrichment process but prevents downstream failures or price mismatches that stall launches. The design ensures your ecommerce team works within an enriched marketing environment while your operations team relies on accurate, sellable SKU data. This design allows operations to work off validated Brightpearl stock levels while marketing maintains the product catalogue in InRiver.
Synchronising marketing taxonomies with operational SKUs
InRiver acts as the master for all enriched product data and digital assets, pushing validated specifications to Brightpearl to create or update SKUs and price lists. The integration logic is designed to bridge the gap between InRiver marketing taxonomies and the rigid operational requirements of a Brightpearl SKU. By treating InRiver as the source of truth, teams avoids data ambiguity where marketing copy and operational data drift apart. We monitor this flow to catch attribute mapping mismatches before they prevent a product from reaching selling status, ensuring that fulfilment teams always have the correct specifications once a record is synchronised.
Orchestrating secure flows via accredited middleware
Leveraging IPaaS with ISO 27001 and SOC 2 and above accreditations ensures secure, efficient integration between Brightpearl (ERP) and InRiver (PIM). IPaaS simplifies connecting Brightpearl ERP and InRiver PIM, reducing manual effort and risk. Benefits include robust data protection, centralised management, and rapid deployment, all while meeting strict security standards. This approach supports business growth and compliance, making integration straightforward and secure.
Surfacing attribute mismatches and sync failures
Dashboards alone rarely flag when an enriched asset in InRiver fails to trigger an update in Brightpearl because of a missing operational attribute. We provide visibility into the data validation layer, surfacing issues where marketing content is complete but the sale status is stuck. Our approach identifies these failures early, distinguishing between system connectivity issues and mapping mismatches. This allows teams to fix specific attribute gaps before they result in missing stock on the storefront or orphaned SKUs in the warehouse.
Handing over product lifecycle management workflows
Training focuses on the ecommerce and operations teams who manage the product lifecycle. We hand over the operating model detailing how InRiver attributes map to Brightpearl fields and how media assets are processed. Your ecommerce team learns to own enrichment exceptions in InRiver, while operations monitors when validated SKUs flow into Brightpearl for stock allocation. Documentation is provided as an operational manual, specifying what to check on a regular schedule to ensure sale statuses are synchronised. Teams learn to interpret alerts from the integration layer to identify whether a launch delay is caused by missing specifications or a system limit. This ensures the business retains control over the product data pipeline.
Resolving pipeline errors and price synchronisation
Support is managed as an ongoing operation. We monitor the product data pipeline to identify and resolve attribute sync errors. If a price list in Brightpearl fails to update after a change in InRiver, the integration layer provides an alert so the issue can be addressed immediately. We own the operational health of the connection, helping to ensure that your product data reflects the current state of both the PIM and the ERP.
Common failures
Incomplete data preventing product creation.
Operational impact: A new product range is fully enriched and signed off in InRiver but fails to appear in Brightpearl because a mandatory attribute is missing or incorrectly formatted. This delays the launch, as stock cannot be booked in against the SKUs and price lists are not updated. The commercial team sees a validated product in the PIM, but operations and finance cannot see a sellable product in the ERP.
Prevention / Action: The integration's trigger for creating a new product in Brightpearl must be a specific 'Ready for Sale' completion state within InRiver. This state should only be achievable after a validation step confirms all data required by Brightpearl is present and correct. The integration itself should have a final validation layer and route any failures to an exception queue for manual review, preventing silent failures.
Price and attribute update latency.
Operational impact: Updates to pricing, specifications, or promotional attributes in InRiver are not reflected in Brightpearl in a timely manner. This can lead to sales at incorrect prices, impacting margins and causing finance reconciliation work. For merchandisers, it creates uncertainty as the data they see in the PIM is not what is live for sale, creating a disconnect between catalogue management and operational reality.
Prevention / Action: Design the integration to handle different data types with different priorities. Price list updates, for example, should be processed through a dedicated, high-priority queue, separate from less critical attribute updates like marketing descriptions. For large catalogues, utilise any bulk update APIs available in Brightpearl and schedule periodic reconciliation jobs to ensure data consistency, rather than relying solely on real-time individual updates.
Orphaned SKUs from product archival.
Operational impact: A product is archived or disabled in InRiver, but the integration does not trigger a corresponding status change in Brightpearl. This leaves an active SKU in the ERP, which can be mistakenly included in stock takes or re-ordered by purchasing teams. Over time, this clutters the master product list in Brightpearl, complicating reporting and creating confusion for the customer service team who may see legacy SKUs.
Prevention / Action: Map the full product lifecycle from InRiver to Brightpearl, not just creation and updates. The integration logic must listen for 'archived', 'disabled', or 'deleted' events in InRiver and explicitly trigger the correct 'inactive' or equivalent status on the Brightpearl product record. This ensures that when a product is removed from the master catalogue, it is simultaneously and safely retired from the operational system.
Mismatched categories and specifications.
Operational impact: Product updates fail because a category or attribute value in InRiver does not have an exact match in Brightpearl. This is common with multi-select fields, custom specifications or controlled vocabularies. These silent failures mean the product appears in Brightpearl with incomplete or outdated information, impacting website filtering, internal searches, and sales channel syndication which rely on complete data.
Prevention / Action: The integration must enforce rigid mapping for all shared taxonomies like categories, brands, and any controlled fields. Before go-live, perform a full mapping audit between InRiver's controlled vocabulary lists (CVLs) and Brightpearl's corresponding custom fields or categories. Build exception handling to immediately alert an administrator if InRiver attempts to push a value that has no defined mapping, preventing data drift between the two systems.
Frequently asked questions
What happens if our marketing team hasn't finished enriching a product in InRiver? Will it create an incomplete SKU in Brightpearl?
Typically, the integration is governed by a 'readiness' status in InRiver to prevent this exact problem. Only when a product is marked as complete, with all required attributes and assets, will the integration trigger the creation of a sellable SKU in Brightpearl. This ensures your Brightpearl item records are not cluttered with products that aren't ready for sale.
We are launching in a new territory with a different price list. How does this integration handle that?
InRiver acts as the central source for all product data, including region-specific pricing and content. The integration uses this to automatically populate the correct price list in Brightpearl when creating or updating SKUs for the new market. This avoids the slow and error-prone process of manually creating and managing separate item records in Brightpearl for each territory.
Our products have complex relationships and many marketing assets in InRiver. How do we ensure they translate correctly to Brightpearl?
This is a primary focus of the integration design, addressing a common failure point where InRiver's marketing taxonomy doesn't map to Brightpearl's operational fields. The connection must translate these rich specifications into the attributes Brightpearl needs to make an item record sellable. Without this, complex products enriched in InRiver can fail to appear correctly in Brightpearl, stalling a launch.
What if we need to change a SKU code after it is live in Brightpearl?
Best practice is to treat the SKU field as immutable once the product is created in Brightpearl from InRiver. Changing a SKU in either system post-launch can orphan the record, breaking the sync for all future inventory and price updates. To retire a product, you would use a status field in InRiver to make it inactive, which then updates the Brightpearl item record to be non-sellable, preserving data integrity.