You sell the same lamp on Shopee, on Lazada and on your own site. You have three units left. Two customers each buy one on different platforms, a third buys at the same moment, and now you owe someone an apology and a refund. This guide explains how Shopee and Lazada stock sync works, which decisions matter most, and what an integration cannot do for you.
Why overselling happens
Each channel keeps its own idea of how many units you have. You updated Shopee at lunchtime, Lazada the day before, and the website sheet whenever someone remembered. A sale on one channel does not change the number on the others until a person or a program does it.
The gap between a sale and the updates is where overselling lives. The longer the gap and the faster the item sells, the more often it bites. The cost is more than a refund. Cancelling an order for lack of stock can affect a seller's standing on a marketplace, and an annoyed customer rarely shops twice. Check each platform's current seller policies for the details.
The core idea: one source of truth
The cleanest fix is to decide where the real stock count lives, and make everything else follow it.
Your source of truth could be a stock sheet, an inventory tool or a small internal system. The rules are:
- One place holds the real number. Not three, and not "whichever was updated last".
- Every sale, on any channel, reduces that number.
- Every channel is updated from that number, never edited by hand.
- Manual changes happen in the source of truth only: a recount, a damaged item, a delivery from the supplier.
This is the design our integrations service builds around. For many Thai sellers the source of truth is simply the stock sheet they already trust, which is fine as long as only one version of it exists and staff update it consistently.
How an integration actually works
Both Shopee and Lazada offer seller APIs through their open platforms. In plain terms, an API lets software read orders and change stock levels on your listings without a person logging in. Getting access typically means registering an application with the platform and receiving approval, and the platforms set limits on how often you may call them. These details change, so we check the current rules at the start of a project rather than relying on memory.
A typical flow:
- A customer orders on Shopee.
- The integration receives the new order, or finds it on its next check.
- It reduces the master stock count for that item.
- It pushes the new count to Lazada and to your website.
- If something fails, it alerts a person instead of failing silently.
On the DigitalRova site this appears as a simple example: a nightly stock sync between Shopee, Lazada and the shop's own stock sheet. Nightly is the simplest version. It is not the only one.
The sync cadence trade-off
How often stock updates is the decision with the biggest effect on both safety and cost.
| Cadence | How it works | Good for | Risk |
|---|---|---|---|
| Nightly | One full reconcile after close | Slow-moving stock, low order volume | Overselling during the day |
| Hourly | Check orders and push counts each hour | Mixed catalogues, moderate volume | A busy hour can still clash |
| On every order | Update other channels as each sale arrives | Fast sellers, last few units | More moving parts to monitor |
Faster is not always better. Each step up costs more to build, adds more calls to the platforms' limits and needs better error alerts. Many sellers do well with a cadence that varies by product: frequent updates for fast movers and low stock, a nightly pass for the long tail.
A sensible compromise is to sync often when stock is low and rarely when it is high. If you have 200 units, a delay of an hour does not matter. If you have two, it does.
What happens when two orders land in the same minute
This is the scenario people worry about, and it deserves an explicit rule. Suppose one unit is left. A Shopee customer and a Lazada customer order within seconds. Both platforms showed "1 in stock" when they ordered. No cadence short of instant can fully prevent that, and even instant updates have a gap.
You have three practical options.
- A safety buffer. Show one fewer unit than you actually have on every channel for fast-moving items, so the last unit is never exposed to a race. Cheap and effective, but it hides the final unit.
- Per-channel allocation. Split stock: for example, give each channel a share and rebalance when one runs out. Predictable, but it can leave stock stuck on a slow channel.
- Accept and handle. For low-value items, allow rare clashes and have a clear process: contact the second customer, offer a refund or a restock date.
Write the rule down. We usually combine a small buffer on top sellers with a clear alert when stock drops below a set level, so a person can intervene before the last unit sells twice.
Variants and bundles
Stock sync usually breaks on products that are not simple.
Variants. A T-shirt in three sizes and four colours is twelve stock-keeping units (SKUs). On Shopee they may be options inside one listing, and on Lazada they may be separate items, each with different codes. The integration needs a mapping table that says "Shopee variant X is Lazada item Y is stock line Z". If you do not have consistent product codes, creating them is the first job.
Bundles. A gift set made of one candle and one diffuser reduces two stock lines when it sells. If the candle sells separately, a bundle sale must lower the candle count too. The integration needs a rule for how a bundle breaks down into its parts. Without it, the bundle can show as available when its components have run out, or the reverse.
Different units. A pack of six on one channel and single items on another need a conversion rule. Write it, test it, and review it whenever you change a listing.
A worked example: setting up a three-channel sync
An illustrative small shop, not a client: a home-fragrance seller in Bangkok with a stock sheet, a Shopee store, a Lazada store and a simple website.
- Count the stock. A physical count, once, with product codes agreed.
- Choose the source of truth. The stock sheet becomes the master. Only one copy exists and only two people may edit it.
- Map every product. Build the table: sheet code, Shopee listing and variant, Lazada item, website product.
- Set the cadence. Hourly for the five best sellers, nightly for the rest.
- Set buffers and alerts. One unit held back on best sellers; a message to the owner's LINE when any item drops below a set level.
- Test with a handful of products. Place test orders on each channel and watch the counts move.
- Roll out the rest and review the error alerts for two weeks.
- Hand over. Documentation, access and the mapping table go to the owner.
The alerts matter as much as the sync. A quiet failure, such as an expired token or a changed listing, is how stock drifts without anyone noticing. Our data and dashboards work can add a single view of stock across channels, including low-stock warnings.
Returns and cancellations
A sync that handles sales but not returns slowly drifts out of true. Decide what happens when:
- An order is cancelled before dispatch. Stock should go back up automatically.
- An item is returned. It should go back into stock only after someone has checked that it is resellable. A damaged return is not stock.
- A refund happens without a return. The count should not change.
The safe pattern is that returned items wait in a "to inspect" state, and a person confirms the condition. Only then does the master count go up and the channels update. It is a small human step that prevents phantom stock.
What an integration cannot fix
Be wary of anyone who promises that sync solves everything.
- Wrong stock in, wrong stock out. If the master count is wrong, the sync spreads the mistake to every channel faster. Count first.
- Messy product codes. Without clear codes, mapping is guesswork.
- Late staff updates. If a delivery arrives and nobody records it, the system cannot know.
- Platform rules and outages. Marketplaces change their APIs and have downtime. A good integration alerts you and recovers; it cannot make the platform behave.
- Physical errors. Mis-picks, breakage and theft change the real count in ways no software sees. Regular cycle counts remain necessary.
Costs and timeline
DigitalRova publishes integrations from ฿39,000, typically in 2 to 3 weeks, fixed in writing after a free scoping call. More channels, many variants or bundles, and messy source data push the scope up, and an internal tool for stock starts from ฿180,000. Platform and hosting costs are listed separately at cost. See pricing for current figures. If you are choosing between connecting your tools and replacing them, our guide to custom software versus off-the-shelf explains how to decide.
When you are ready, tell us which channels you sell on and we will give an honest view of what a sync would involve.