Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Card sales taken on iZettle reach Odoo as recorded transactions and product data flows outward, so a mobile or market till stops being a separate little business with its own paperwork.
A small till used at markets, pop-ups or a counter produces real revenue and almost no records that Odoo can use. Sales sit in the payment app, somebody totals them at the end of the week, and stock sold from the van is deducted from Odoo whenever anybody remembers to do it. Product prices on the till drift away from the ones the business actually agreed. Connecting Odoo and Izettle through Alumio joins the two: transactions reach Odoo as they happen, product and price data flows out to the till, and stock sold anywhere reduces one shared figure.
DATA THAT FLOWS BETWEEN THEM
Card transactions
Payment types
Refunds
Product records
Prices
Stock movements
Transactions reach Odoo continuously rather than as a weekly total, so revenue is recorded on the day it was earned and reconciliation stops being a memory exercise.
Units sold from a market stall or van reduce the same Odoo stock figure the webshop reads, so the online catalog stops offering products that left in somebody's car.
Product and price updates flow from Odoo to the till, so what a customer pays at a market matches the agreed price rather than whatever was last entered on the device.
A refund on the till reaches Odoo as its own record rather than being netted off a weekly figure, so returns stay visible instead of being hidden inside a total.
A card sale taken on the till is recorded in Odoo with its payment type and its lines, so the day's trading appears in the accounts without anyone reading a payment app summary and then typing that total in later.
Units sold away from the warehouse reduce the Odoo stock position as the sale is recorded, so a webshop customer is not sold the last unit of something that was already handed over at a market that same morning.
Product and price changes made in Odoo reach the till device, so staff selling at an event always charge the current price without anybody editing products on the device or applying manual corrections afterwards.
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.
More can be connected, and the webshop is the usual third, because the same stock is being sold in both places and neither should be able to oversell it. Alumio keeps Odoo as the single position both read, so a market day and an online promotion cannot quietly commit the same units to two different customers.
Yes. Transactions, payment types and refunds are recorded in Odoo as they occur, with Alumio reaching the till through the interface it exposes, as it would any reachable system. Product and price data can travel outward too, so the device reflects Odoo rather than keeping its own gradually diverging copy of the catalog.
Alumio reaches each system through the interface it exposes and the mapping is configured, replacing the weekly totalling routine a small till usually relies on. Payment and till setups vary by business and by country, so the Code Transformer covers a tender or coding rule that mapping on its own cannot describe.
At the transaction rather than at the end of the day, which matters more for stock than for accounting. Recording per transaction means the Odoo stock position updates while the market is still trading, so the webshop is not selling the same units. Businesses that prefer a single daily entry for bookkeeping can still have that, with stock handled separately at transaction level.
Retries handle a till that was briefly out of signal, without anyone intervening. Every transaction message is recorded with its content and the connection watched in real time, so a refusal reaches you as a notification naming the transaction and the reason it failed. Nothing is recorded twice, and an unsent sale stays queued rather than going missing between the till and the ledger.
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)
