Multi-Channel eCommerce Aggregator: One Dashboard for Products, Orders, Inventory and Shipping
A seller listing the same product on Shopify, WooCommerce, two Mirakl marketplaces and a dropship portal is running five businesses that happen to share a warehouse. We built a Laravel SaaS platform that treats them as one: a single canonical catalogue, a dynamic integration layer that speaks each channel's API dialect, and inventory that moves everywhere the moment a unit sells anywhere.
Project Overview
- Industry
- eCommerce · Retail · Marketplace operations
- Product Type
- Multi-tenant SaaS, sold to eCommerce sellers
- Problem
- Products, stock and orders scattered across many storefronts and marketplaces with no single source of truth
- Services
- SaaS platform engineering, marketplace API integration, integration framework design, dashboard development
- Tech Stack
- Laravel (PHP), Angular, MySQL, REST APIs, queued workers, multi-tenant architecture
- Integrations
- Shopify · WooCommerce · Maropost Commerce Cloud · Mirakl (Baby Bunting, Freedom) · Virtualstock (Harvey Norman) · Dropshipzone · Seller Center (THE ICONIC) · The Block Shop
At a Glance
- What it does: lets an eCommerce seller manage products, orders, inventory, shipping and promotions across every sales channel from one application.
- The core idea: one canonical product record in the platform, and a channel adapter that translates it into whatever shape each marketplace expects.
- Why it scales: a dynamic API integration framework - field mapping, auth style, endpoints and sync rules are configuration, so a new channel is onboarded rather than coded from scratch.
- The problem it solves: overselling. When stock is tracked per channel, the same last unit can be sold three times. Here, one sale decrements a single shared pool that pushes to every channel.
- Channels integrated: Shopify, WooCommerce, Maropost Commerce Cloud, Mirakl marketplaces (Baby Bunting, Freedom), Virtualstock (Harvey Norman), Dropshipzone, Seller Center (THE ICONIC), The Block Shop and others.
- Stack: Laravel (PHP) backend, Angular front end, MySQL, multi-tenant SaaS architecture.
The Challenge
Selling on one channel is a business. Selling on eight is an integration problem wearing a business costume.
Our client's sellers had the same catalogue spread across their own Shopify and WooCommerce storefronts, a Maropost store, marketplaces run on Mirakl, a dropship feed into Harvey Norman through Virtualstock, and a Dropshipzone supplier account. Every one of those had its own product schema, its own idea of what an order looks like, and its own authentication scheme. Keeping them aligned was a person with a spreadsheet and a strong memory.
Four problems came out of that:
- Overselling. Stock counted per channel means the same last unit is available in eight places at once. The cancellation, the refund and the marketplace performance penalty all follow.
- Eight versions of the truth. A price change or a new image had to be repeated eight times and inevitably was not. Listings drifted apart.
- Orders in eight inboxes. Fulfilment staff worked from a different screen per channel, and tracking numbers went back the same way - manually, one at a time.
- Every new channel was a project. Adding a marketplace meant another bespoke integration, another deployment, another thing to maintain. Growth was gated by engineering.
The Solution: One Catalogue, Many Adapters
The platform holds one canonical product record per SKU - attributes, images, pricing rules, stock pool. Channels never own product data; they receive a projection of it. Each channel has an adapter that knows three things: how to authenticate, how to translate the canonical record into that channel's payload, and how to translate that channel's orders back.
A round trip looks like this
- Author once. The seller creates or edits a product in the Angular dashboard. It lands in MySQL as the canonical record.
- Map to channels. Field mappings decide how that record appears per channel - category taxonomy, attribute names, title format, channel-specific pricing.
- Publish through the adapter. A queued job pushes to each enabled channel using its own protocol and credentials, and records the channel's returned identifier against the SKU.
- Pull orders back. Adapters poll or receive orders, normalise them into one order model, and drop them into a single fulfilment queue.
- Decrement once, push everywhere. Sales on any channel reduce the shared stock pool, and the new figure is propagated to every other channel.
- Dispatch and confirm. Shipment and tracking data is written back to the originating channel in the format it expects.
Key Features & Modules
Dynamic API Integration Framework
The part that makes this a product rather than a pile of one-off scripts. Every channel implements the same adapter contract - authenticate, push product, push stock, push price, pull orders, push dispatch - on top of a configuration layer holding endpoints, credentials, field mappings, taxonomy mappings and sync intervals. Adding a channel means a thin adapter and configuration, not touching the core. Where marketplaces share a platform, one adapter serves several: the Mirakl integration covers Baby Bunting and Freedom because both run on Mirakl.
Product & Catalogue Management
One canonical record per SKU, with variants, attributes, images, and per-channel overrides where a marketplace demands its own title length or category tree. Bulk editing and CSV import handle catalogues too large for a per-item UI. Overrides sit on top of the canonical record rather than replacing it, so a global price change still reaches channels with their own title or category mapping.
Inventory Sync & Oversell Prevention
Stock lives in one pool per SKU. A sale on any channel decrements that pool and triggers a push to every other channel. Buffers can hold back a few units on a higher-risk marketplace, and low-stock thresholds pull a listing before it goes negative - the feature sellers buy the platform for, since overselling costs a refund, a bad review and a ranking penalty that outlasts the sale.
Unified Order Management
Orders from every channel are normalised into one model - line items, buyer details, shipping method, channel reference - and land in a single queue. Staff pick, pack and dispatch from one screen without knowing which marketplace an order came from. The originating channel identifier travels with the order, so status and tracking write back to the right place in the right format.
Shipping & Dispatch
Shipment creation, carrier and tracking capture, and write-back to the source channel. Dropship channels are the awkward case: with Virtualstock the retailer's order arrives through the platform, so the dispatch confirmation goes back the same way - the supplier's own courier data mapped into the retailer's expected fields rather than simply echoed.
Promotions & Pricing
Pricing rules run centrally - markups, per-channel margins, sale windows and promotional pricing - then flow out through the same adapter path as any other product change. Channel-specific commission structures can be reflected in the rule, so a marketplace with a higher take rate does not quietly sell at a loss.
Multi-Tenant SaaS Architecture
The platform is sold to many sellers, so tenants are isolated at the data layer, credentials are stored per tenant, and background jobs are queued per tenant so one seller's large catalogue push cannot starve another's order sync. Onboarding a new seller is an account creation and a set of channel connections, not a deployment.
A Closer Look
Screenshots from the live platform: the product catalogue, per-channel attribute filters, and the promotions engine.
Channels We Integrated
Every channel below is a real integration in the platform. The notes describe what each one demands, which is the generic part "we integrate with everything" copy always leaves out.
| Channel | Type | What the integration has to handle |
|---|---|---|
| Shopify | Storefront | Admin API over OAuth. Products, variants, inventory levels per location, orders and fulfilments; webhooks for near-real-time order capture. |
| WooCommerce | Storefront | REST API with consumer key and secret over HTTPS. Product and stock updates, order retrieval; behaviour varies with the store's plugins, so mappings are per-tenant. |
| Maropost Commerce Cloud (Neto) | Storefront / ERP | A single endpoint with the action named in a header - NETOAPI_KEY plus NETOAPI_ACTION - JSON in and out. Actions such as Get Item, Update Item, Get Order and Add Order rather than REST resources, which needs its own adapter shape. |
| Mirakl - Baby Bunting | Marketplace | Mirakl seller API. Offers, order acceptance and dispatch against the operator's category and attribute taxonomy; catalogue submissions are processed asynchronously, so the adapter tracks import status rather than assuming success. |
| Mirakl - Freedom | Marketplace | Same Mirakl adapter, different operator, different taxonomy and commission rules - the clearest payoff of the framework: one integration, several marketplaces. |
| Virtualstock - Harvey Norman | Dropship | REST/JSON with Basic authentication, rate-limited to 250 requests per minute with 429 responses, and webhooks for order and tracking updates that retry over 24 hours. A CSV-over-SFTP path exists for suppliers who cannot use REST. |
| Dropshipzone | Dropship / Supplier | Token authentication: the /auth endpoint returns a JWT valid for roughly 8 hours, so the adapter re-authenticates on a 401 rather than on a timer. Retailer orders arrive a couple of minutes behind schedule because of scheduled sync intervals. |
| Seller Center - THE ICONIC | Marketplace | Seller-portal API for listings, orders and fulfilment, with the operator's own category and attribute requirements. |
| The Block Shop | Marketplace | Curated marketplace listing and order flow. |
How We Built It
Nothing about this project was hard in isolation. The difficulty is that eight APIs fail in eight different ways, and a sync platform is judged entirely on what it does when they do.
Engineering decisions worth naming
- Queued everything. Every channel call runs as a Laravel queued job. A marketplace being slow or down delays one queue, not the dashboard and not the other seven channels.
- Rate limits as a first-class setting. Virtualstock allows 250 requests per minute and answers with 429 beyond that. Per-channel throttles and backoff live in the adapter configuration rather than being discovered in production.
- Re-authenticate on failure, not on a schedule. Dropshipzone tokens last about eight hours. Refreshing on a timer drifts; catching the 401 and re-authenticating is the version that survives a deploy at the wrong moment.
- Asynchronous imports need status tracking. Mirakl processes catalogue submissions asynchronously. The adapter records the submission and follows up on its outcome, so a rejected import surfaces as a rejected import instead of a product that silently never appeared.
- Idempotent writes. Every push carries a deterministic key, so a retry after a timeout updates rather than duplicates. Duplicate listings in a marketplace are much harder to clean up than to prevent.
- Stock pushes collapsed. Rapid successive sales collapse into one outbound update per channel per interval instead of a burst, which keeps the platform inside rate limits during a sales spike - exactly when it matters.
- A visible sync log. Every push and pull is recorded with its payload summary, response and outcome. When a seller says "this listing is wrong on Freedom", the answer is a lookup, not an investigation.
Results & Impact
The platform runs in production as a multi-tenant SaaS. What changed for the sellers using it:
- Overselling stopped being structural. One stock pool, pushed everywhere, replaces eight independent counts that were always slightly wrong.
- One catalogue, one edit. A price, image or description change is made once and reaches every channel on the same path.
- One fulfilment screen. Orders from storefronts, marketplaces and dropship feeds arrive in a single queue in one shape.
- New channels are onboarding, not engineering. A thin adapter plus configuration, rather than a bespoke build and a release.
- Failures are visible. A sync log with per-channel outcomes turns "something is out of date somewhere" into a specific record with a specific error.
Services We Provided
- Multi-tenant SaaS platform architecture
- Laravel (PHP) backend engineering
- Angular dashboard development
- MySQL schema design for catalogue, inventory and orders
- Dynamic API integration framework design
- Marketplace and storefront API integrations
- Inventory synchronisation and oversell prevention logic
- Order normalisation and fulfilment workflow
- Shipping and dispatch write-back
- Sync logging, monitoring and error handling
Who Built This
Ankush Tarika, Senior Laravel / Angular Developer at Fly IT Solution, led the backend and integration work on this platform and has spent 10+ years building Laravel SaaS products that connect third-party commerce APIs. On this project they were responsible for the integration framework, the marketplace adapters, the inventory synchronisation logic and the multi-tenant job architecture.
Fly IT Solution builds custom web and mobile software, with teams in Mohali, India and Minneapolis, USA. Related work: our Patreon tier-based secure video platform and our Accuro EMR integration for a HIPAA-compliant patient flow platform - both, like this one, projects where the value sat in the integration layer rather than the interface.
Multi-Channel eCommerce Aggregator - FAQs
Common questions about overselling prevention, marketplace coverage, and how the integration framework adds a new channel.
What is a multi-channel eCommerce aggregator?
It is a single application that manages products, inventory, orders, shipping and promotions across every sales channel a seller uses. Instead of logging into Shopify, WooCommerce and each marketplace separately, the seller works in one dashboard, and the platform synchronises changes out to each channel and pulls orders back in.
How does the platform stop overselling across marketplaces?
By holding one stock pool per SKU rather than a separate count per channel. A sale on any channel decrements that shared pool and immediately pushes the new quantity to every other channel. Per-channel buffers can hold back a few units on higher-risk marketplaces, and low-stock thresholds can pull a listing before the count reaches zero.
Which marketplaces and platforms does it integrate with?
Shopify, WooCommerce, Maropost Commerce Cloud, Mirakl-powered marketplaces including Baby Bunting and Freedom, Virtualstock for Harvey Norman dropship, Dropshipzone, Seller Center for THE ICONIC, and The Block Shop. Because the integration layer is configuration-driven, further channels are added without changing the core platform.
What is a dynamic API integration solution?
It is an integration layer where each channel's differences - endpoints, authentication style, field mappings, category taxonomy, sync frequency and retry policy - are stored as configuration rather than written into code. Each channel implements the same small adapter contract, so adding a new marketplace is an onboarding task rather than a development project.
Can one integration cover more than one marketplace?
Yes, when the marketplaces share a platform. Baby Bunting and Freedom both run on Mirakl, so a single Mirakl adapter serves both - only the operator's taxonomy, credentials and commission rules differ. The same applies to any other Mirakl-powered marketplace a seller wants to add.
How do you handle marketplace rate limits and API failures?
Every channel call runs as a queued job with per-channel throttling and exponential backoff. Virtualstock, for example, allows 250 requests per minute and returns 429 beyond that, so its throttle is set in configuration. Writes carry a deterministic key so a retry updates rather than duplicates, and every attempt is recorded in a sync log with its outcome.
Does it work for dropship suppliers as well as own storefronts?
Yes. Dropship channels behave differently from storefronts: with Virtualstock the retailer's order arrives through the platform and the despatch confirmation must return the same way, and Dropshipzone delivers retailer orders a couple of minutes behind because of scheduled sync intervals. Those behaviours are modelled in each adapter rather than assumed away.
How long does it take to add a new sales channel?
Once the framework is in place, a channel that uses a conventional REST API is typically a matter of days rather than weeks - a thin adapter plus mapping configuration. The variables are how unusual the API is, whether catalogue submission is asynchronous, and how much category and attribute mapping the marketplace demands.
Selling on More Channels Than You Can Keep in Sync?
If your catalogue lives in several places and your stock count lives in your head, we have built this before. Tell us which channels you sell on and where the data breaks, and we will come back with a scoped approach.