Lightspeed and InRiver
Integration Agency & Consultants
Product data inconsistencies usually become visible at the till when enriched attributes from InRiver fail to surface correctly in Lightspeed POS. These gaps often lead to transactional errors and reporting drift. We focus on the operational link between master data enrichment and point-of-sale accuracy, ensuring that enriched product data flows into Lightspeed to support reliable transactions and clean reporting.
Auditing system gaps and integration requirements
We connect your Lightspeed POS and InRiver PIM platforms quickly, ensuring your POS and PIM integration works efficiently. Our consulting services are invaluable, offering system audit expertise that uncovers inefficiencies and integration gaps between Lightspeed and InRiver. This empowers both our consultants and your team to take decisive action, keeping your tech ecosystem running smoothly. With our audits, you can be confident your POS and PIM systems are optimised, helping you deliver a consistently excellent customer experience.
Solution Design
Design decisions for Lightspeed and InRiver focus on the link between enriched product data and transactional POS requirements. InRiver typically serves as the master for product enrichment, while Lightspeed often remains the authority for store-level pricing and stock levels. We address the trade-off between real-time attribute updates and system stability. Pushing every PIM change instantly can impact system performance during peak trading, so we typically use a defined schedule for enrichment updates while prioritising critical transactional data. This helps prevent POS lag during busy store hours. The resulting model ensures finance can reconcile sales against accurate SKU data, while retail ops trust that the description on the terminal matches the digital catalogue.
Managing the PIM to POS dataflow
The integration maintains a flow where InRiver owns the enriched product record and Lightspeed consumes it to drive transactions. We map InRiver entities to the Lightspeed item structure, ensuring product variants, categories, and attributes are correctly aligned before they reach the store floor. Data commonly moves on a defined schedule to protect system performance, with updates for new SKU launches prioritised. Issue detection is built into the flow, catching mapping errors or missing mandatory fields before they cause a transactional failure at the POS. This helps ensure your master data remains consistent across retail channels.
Securing the integration via accredited middleware
Leveraging IPaaS with ISO 27001 and SOC 2 and above security accreditations, Lightspeed POS and InRiver PIM integrations are delivered efficiently and securely. IPaaS connects Lightspeed POS with InRiver PIM, automating data flow and reducing manual effort. Benefits include centralised management, robust security, and simplified compliance. This approach ensures reliable, scalable integration for both Lightspeed and InRiver, supporting secure POS and PIM operations while meeting the highest security standards.
Surfacing sync gaps and mapping errors
Standard dashboards often miss the silent failures that erode data integrity. We focus on visibility into sync gaps, where an item is updated in InRiver but fails to reflect in Lightspeed due to a mapping issue or an invalid attribute. The monitoring layer surfaces these exceptions, allowing your team to identify which SKU requires attention. Instead of waiting for a store to report an error, you can see the sync status across the integration. This proactive approach helps ensure the link between your PIM and your cash registers remains accurate.
Handing over ownership to internal teams
Handover ensures your ecommerce, retail ops, and finance teams own the new operating model. Training is anchored in the specific design of your Lightspeed and InRiver setup, not a generic product walkthrough. We define who owns each exception type, from product attribute mismatches to POS sync delays. Your team learns what to check on a defined cadence, ensuring they can interpret alerts from the integration layer before issues compound. Documentation is delivered as a practical operational reference, written for the people running the business rather than a technical archive. This approach ensures that when Cogent steps back, your internal teams have the clarity to maintain product data integrity.
Governance and resolving post-launch data failures
Post-launch support focuses on maintaining data integrity between InRiver and Lightspeed POS. Monitoring identifies sync failures and attribute mismatches before they reach the point of sale, reducing the risk of transactional errors. If a retail team identifies missing or incorrect product information, we provide an escalation path to resolve the underlying technical issue. This includes monitoring the integration layer to ensure enriched data flows correctly, preventing operational gaps that require manual correction. Issues are addressed on a defined schedule to keep store operations consistent.
Common failures
Mismatched product and variant structures
Operational impact: Lightspeed uses a strict parent-child matrix for products with variants, like size or colour. If InRiver's data model for a product family does not map cleanly to this structure, SKUs can be created as standalone products in Lightspeed. This clutters the product catalogue, breaks merchandising at the point of sale, and forces manual clean-up by operations and merchandising teams.
Prevention / Action: The integration's logic must be designed to correctly identify parent products and their associated child variants from InRiver data before transmission. This requires defining a specific attribute in InRiver to act as the parent identifier. The integration should then use this key to group all related SKUs under the single parent matrix item when creating or updating data in Lightspeed.
Orphaned or outdated product records
Operational impact: When a product is deleted or its enrichment status is retracted in InRiver, the change may not automatically cascade to Lightspeed. This leaves 'ghost' products active in the POS catalogue with outdated pricing or attributes, causing transaction errors and customer confusion. It also means sales reports can include data for SKUs that the master data system no longer governs, creating reconciliation work for the finance team.
Prevention / Action: The integration must explicitly handle deletion and un-enrichment events. Rather than only pushing new data, the process must include a mechanism to obsolete corresponding items in Lightspeed. This is often achieved through a scheduled job that compares active SKU lists from both systems, identifies discrepancies, and sends deactivation commands for records that only exist in Lightspeed.
Incorrect attribute type mapping
Operational impact: InRiver's flexible attributes, such as multi-value lists (CVLs), often do not align with standard Lightspeed data fields. Pushing this data without transformation can result in missing product specifications at the point of sale. If a mandatory Lightspeed field like 'Category' is not correctly populated from an InRiver source, the entire product synchronisation can fail, leaving the SKU unavailable for sale.
Prevention / Action: A transformation layer or logic set should be implemented within the integration to map InRiver's controlled vocabularies and other custom fields to the specific formats Lightspeed requires. This involves agreeing a clear data map in the design phase. The integration process should also validate that all mandatory Lightspeed fields are populated before attempting the data push, logging any failed SKU for investigation.
Frequently asked questions
How does the integration handle product variations like size and colour between InRiver and Lightspeed?
Lightspeed Retail uses a strict parent-child structure for product matrices, such as t-shirts with different sizes and colours. Product data sent from InRiver must be correctly organised to match this model, otherwise the matrix item record will fail to create or update in Lightspeed. This can result in new size or colour SKUs being unavailable for sale at the point of sale.
What happens in Lightspeed when a product is deleted or unpublished in InRiver?
Simply deleting a product entity in InRiver does not automatically remove the corresponding item record from Lightspeed POS. The integration must be explicitly configured to handle this, for example by setting the Lightspeed item to 'inactive' or flagging it for manual review. Without this rule, discontinued products could remain available for sale, leading to stock and fulfilment errors.
Our product catalogue in InRiver includes bundles and kits. How are these represented in Lightspeed?
Lightspeed does not have a native 'kit' or 'group' structure equivalent to how they might be built in InRiver. The integration must therefore model these complex products, typically by creating them as distinct items in Lightspeed whose components are tracked separately. This ensures that when a bundle SKU is sold, stock levels for the correct constituent items are decremented.
How are custom attributes and specifications from InRiver managed in Lightspeed?
The integration maps InRiver fields, including from controlled vocabulary lists (CVLs), to corresponding fields in Lightspeed, which may include custom fields or metafields. A common failure occurs when mapping a multi-select field from InRiver to a single-select field in Lightspeed, causing data truncation. This results in incomplete product information appearing on the item record at the point of sale.