Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
A trade buyer ordering forty of something is not simply a Shopify shopper having a very good day, and Brightpearl has to be told which of the two kinds of order it is actually receiving.
Brightpearl runs retail and wholesale off one stock pool and one customer list, which is what makes it useful and also what makes the distinction matter. A consumer order and a trade order want different prices, different terms, different fulfilment priority and different credit treatment, and a Shopify order arriving with none of that attached gets treated as whichever the default happens to be. Connecting Shopify and Brightpearl carries the trading relationship with the order, so the warehouse and the ledger both know which kind of customer they are serving.
DATA THAT FLOWS BETWEEN THEM
Orders
Customers
Price lists
Stock levels
Fulfilments
Refunds
A Shopify order reaches Brightpearl carrying the trading relationship behind it, so a trade account is not processed on consumer terms because nothing said otherwise.
A trade account is charged from the Brightpearl price list it belongs to, so the same item can cost two things without anybody maintaining a second Shopify catalogue for it.
When Brightpearl ships, the Shopify order follows with its tracking, so a consumer sees progress in their account rather than waiting for an email somebody sends by hand.
Adding trade customers extends the rules already in place, so a brand starting to sell wholesale does not have to rebuild the Shopify connection to accommodate it.
A Shopify order is created in Brightpearl with the customer resolved and their relationship attached, so the price applied, the terms offered and the priority it is given all follow from who placed it rather than from a default.
Alumio publishes the Brightpearl stock position to Shopify on the cycle you set, so what the shop offers already accounts for what wholesale has committed and a consumer is not sold something a trade order is waiting on.
When Brightpearl records a fulfilment, Alumio updates the Shopify order with the tracking reference, so the customer follows the parcel from their own account instead of writing in to ask where it is two days after despatch.
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 second connection most brands make is the portal trade customers actually order through, because a wholesale buyer will not use a consumer checkout and Shopify is not trying to be one. Brightpearl holds the account and the terms, and the ordering experience sits elsewhere. Alumio holds that connection alongside this one, so both kinds of order reach the same stock and the same ledger.
It can, and the customer resolution happens before the order is created. Alumio matches the Shopify buyer to the Brightpearl customer they belong to, attaches the relationship, and creates the order with that context. Stock travels back on the cycle you choose and fulfilments return as they are recorded, so the shop reflects the warehouse without anybody maintaining it.
No, this is configured rather than coded. The channel spreadsheet somebody reconciles nightly is what goes, along with the habit of checking whether a large Shopify order was really a trade customer. How a buyer resolves to a Brightpearl customer, and what each relationship implies, are entries in Alumio. Where a price has to be derived per relationship, the Code Transformer takes it.
No, and treating them alike is what makes a shared stock pool painful rather than useful. Brightpearl can hold both against one customer list, but a trade order carries terms, a credit position and a fulfilment priority that a consumer order does not, so a Shopify order arriving without its relationship is guessed at. Deciding what each relationship implies is the work that makes one pool workable.
A fulfilment confirmed in Brightpearl against a Shopify order that was already refunded is the failure with goods attached, because the parcel leaves and the money has gone back. Alumio monitors each transfer live and records the order state it read with the fulfilment it produced, so a mismatch raises an immediate alert naming both and the reason. Retries run where configured, so nothing is quietly shipped.
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)
