Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
What SAP holds and what a marketplace is allowed to sell are two entirely different numbers, and Linnworks is where the second one gets decided rather than simply assumed to be the first.
Selling the same stock on four marketplaces means four systems each believing they have all of it. Oversell on one of them and the consequence is not an apologetic email, it is a metric recorded against the account and eventually a suspension, which costs a great deal more than the order ever did. The usual protection is to hold a buffer back and quietly accept selling less than the business actually has. Connecting SAP and Linnworks makes the figure each channel is given a deliberate one, so the buffer is a decision rather than a guess somebody made once and nobody has revisited.
DATA THAT FLOWS BETWEEN THEM
Stock levels
Allocations
Orders
Order lines
Despatches
Products
Each marketplace is given the quantity the business will commit to it rather than everything SAP holds, so an oversell is not how anybody discovers where the limit was.
How much is held back is a rule somebody set and can change, rather than a number chosen years ago by a person who has since left and never revisited by anybody.
Orders from every channel reach SAP through Linnworks in the same shape, so the warehouse works one list rather than four, and nobody is reconciling between marketplaces by hand.
The metric a marketplace scores you on counts cancellations, so getting the figure right is worth something in account standing rather than only in the margin on one order.
When the SAP position changes, Alumio gives Linnworks the figure to publish and the allocation rule decides what each channel sees, so four marketplaces are not all selling the same last unit at the same moment.
When a channel order is despatched, the confirmation reaches SAP against the line it belongs to, so the stock position the next allocation is calculated from reflects what actually left the building this morning.
When a buyer cancels while the order is being picked, the state is visible before the confirmation goes back, so nobody despatches against a line that the marketplace has already closed and refunded to the customer.
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.
The carrier is the one that closes the loop. A marketplace scores dispatch performance as well as cancellations, and the proof of dispatch sits with whoever collected the parcel rather than with either of these systems. Alumio holds that connection alongside this one, so the tracking that protects the account reaches the channel without anybody copying it.
Yes, in both directions and on separate cycles, because stock and orders do not need the same timing. Stock moves toward the channels on the frequency you set, orders come back as they arrive, and the allocation rule is applied before any figure is published. What can be read and written is whatever each side exposes for it.
No, and the part that is not technical is the part that matters. Somebody has to decide what each channel is allowed to sell, which is a commercial judgement about risk and volume rather than a setting. Once decided it is configuration you can read and change. An allocation rule too awkward to state that way goes to the Code Transformer.
Less than all of it, and the right answer differs by channel. A marketplace that penalises cancellations heavily deserves a more conservative figure than one that does not, and a fast-moving product deserves a different rule from a slow one. What the connection does is make that a rule rather than a habit, so it can be reviewed when the mix changes instead of surviving by nobody questioning it.
The damaging one is a pick confirmed against a line the buyer already cancelled, because the parcel goes out and the refund has gone with it. Alumio records the order state at the moment the pick was confirmed, so the sequence is checkable. Each transfer is monitored live and logged with what it carried, a refusal alerts with the reason, retries run where configured, and nothing is lost silently.
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)
