Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
A Bol offer promises a delivery date and closes at a cut-off, so the WooCommerce figure behind it has to be what the warehouse can still dispatch today rather than everything that is on hand.
A Bol offer is a promise with a clock on it. The listing carries a delivery expectation and a dispatch cut-off, and a shopper who orders at four in the afternoon has been told when the parcel arrives. WooCommerce holds the stock, and if the two are not connected the offer keeps taking orders through the afternoon on a figure from the morning, so the cut-off is missed by an order that should never have been accepted. Connecting WooCommerce and Bol keeps the offer and the dispatchable figure in step, so the promise on the listing is one the warehouse can still keep.
DATA THAT FLOWS BETWEEN THEM
Offers
Stock levels
Delivery promises
Marketplace orders
Shipment confirmations
Returns
Stock from WooCommerce updates the Bol offer on the schedule you set, so the quantity a shopper can buy is a quantity that is still on the shelf this afternoon.
Because the offer closes when the dispatchable figure runs out, the delivery promise Bol shows is one the warehouse can still meet rather than one it will miss by a day.
One figure feeds both the webshop and the marketplace, so a channel does not sell the last unit twice while somebody reconciles two separate stock screens by hand each morning.
Returns from Bol reach WooCommerce alongside web returns, so a customer's history sits in one place and the stock comes back into exactly the same figure it left from.
Alumio publishes the WooCommerce figure you nominate to the matching Bol offer on the schedule you choose, holding back a buffer, so an offer closes shortly before the warehouse runs out rather than a day after it has.
A Bol order is created in WooCommerce as it arrives with its marketplace reference kept, so it is picked and packed in the same flow as a web order instead of from a separate seller screen somebody has to remember to open.
A return registered on Bol is written into WooCommerce against the original order, so the refund, the stock movement and the customer record are all handled once rather than twice in two systems that then have to agree.
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 Bol does not tell you is why somebody was unhappy, only that they were, and that gap is where the next connection goes. A survey tool is the usual addition, because a marketplace rating arrives as a score with no explanation attached, while WooCommerce holds the order it belongs to. Alumio holds both connections, so the answer a customer gives sits against the order rather than in a monthly summary.
Which fulfilment model each offer uses is settled before anything else, because it decides who holds the stock. Alumio publishes WooCommerce availability to the Bol offers you nominate, with the buffer you choose, and creates Bol orders in WooCommerce as they arrive. Offers fulfilled by the marketplace are excluded from the stock feed, so nothing is published twice against the same units.
No, and the reason is that Bol does not negotiate. The delivery promise, the cut-off and the required fields are the channel's, so there is nothing to build, only decisions to record: which WooCommerce offers publish, at what buffer, on what schedule. Those are settings in Alumio's interface. Where a business calculates its channel price on a rule of its own, the Code Transformer takes that step.
A dispatch window, and that is the part a stock figure has to respect. Bol shows a shopper when the parcel will arrive and closes the day at a cut-off, so an order accepted on stale WooCommerce availability is a promise the warehouse cannot keep even though the sale went through. Publishing a dispatchable figure, rather than everything on hand, is what keeps the promise and the shelf agreeing.
An order accepted after the cut-off is the failure to catch, because it looks like a sale. The Bol offer and the WooCommerce figure behind it are both recorded at each update, so an offer that could not be changed is flagged at once with its reason, retries run where configured, and per-route alerts cover no activity, meaning nothing sits quietly on a figure nobody refreshed.
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)
