Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Product records, kit components and the images each one points at travel from Odoo into Inriver, so the catalog describes what a customer receives rather than what the warehouse happens to pick.
Odoo can sell a kit as one product and pick it as several, which is sensible for a warehouse and confusing for a catalog. Inriver has to decide whether the customer is buying one thing with a specification or a bundle of parts with their own pages, and if nobody decides, both appear. A shopper compares a kit against one of its own components, the images belong to the parts rather than the product, and the page a customer lands on is not the page anybody meant to publish. Connecting Odoo and Inriver settles the shape before anything is published.
DATA THAT FLOWS BETWEEN THEM
Product records
Kit components
Item codes
Sales prices
Asset references
Product relationships
An Odoo kit reaches Inriver as the product a customer buys, with its components held as relationships, so the catalog shows one page rather than one page per part.
Images and documents travel as references rather than as copies, so the asset a page shows is the asset somebody approved and updating it does not mean republishing.
Components a customer can also buy separately keep their own Inriver records, so a spare part stays findable in its own right without competing with the kit it belongs to.
Because the shape is decided before publication, nobody discovers at launch that the same physical product exists twice in the catalog under two different codes.
Alumio reads an Odoo kit with its components and creates the Inriver product a customer buys, holding the parts through the relationship type Inriver's model exposes, so the catalog carries one page with the composition behind it.
Asset references travel from Odoo to Inriver rather than the files themselves, so a page points at the approved image in the place it lives and a replacement reaches every channel without a second import being run for each one.
A component that is also sold on its own keeps its own Inriver record linked to the kit, so a customer looking for a replacement part finds it without the kit and the part appearing to be one and the same product.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
What the catalog needs and the ERP will never hold is the guide, and for most businesses that is the printed version. A catalogue production house is the common addition, because Inriver holds finished product content and a print run needs it laid out and proofed, while Odoo has no opinion on either. Alumio holds that connection alongside this one, so the printed page and the online page are built from the same approved product.
Asset references come first, because getting them wrong means republishing everything later. Alumio reads Odoo product records, kit components and the references to where images and documents are stored, and writes them to the Inriver attributes that accept a reference, so a page points at the stored asset rather than a copy. Prices and codes follow on the schedule you set, and products not yet ready stay in Inriver.
No, and the useful distinction is a reference rather than a file. Alumio writes the pointer to where an Odoo asset lives instead of moving the file, which is configuration in the interface, and it is why a replaced image does not require a second pass through every channel. Because Inriver models are built per implementation, custom logic remains available through the Code Transformer where a relationship type has no direct equivalent.
The product the customer buys, with the parts held as relationships behind it. Odoo can sell a kit as a single item and pick it as several, so the catalog has to choose which of those a page describes, and publishing both puts a kit and its own component in front of the same shopper. Deciding that Inriver holds the sellable product and links the components keeps the catalog matching what arrives in the box.
An asset link that broke is the failure here, and the page keeps loading, which is what makes it slow to notice. The Odoo record and the reference that failed are both retained, the alert is immediate, with the product and the reason named, and retries run where configured. The previous reference stays live, so no Inriver page publishes with a missing image and nothing goes unrecorded.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
