--- title: "Syncing Stock Between Your Website, Marketplaces and Spreadsheets" url: https://phatdev.net/en/blog/sync-inventory-web-marketplace lang: en updated: 2026-10-21 alternate: vi: https://phatdev.net/vi/blog/sync-inventory-web-marketplace markdown: https://phatdev.net/en/blog/sync-inventory-web-marketplace.md --- # Syncing Stock Between Your Website, Marketplaces and Spreadsheets > One last speaker, three orders at once. Why stock drifts apart, five ways to handle it from manual work to API links, and where to start. Categories: Backend | Published: 2026-10-21 | Level: Intermediate | 6 min read Tags: inventory, sync, api, marketplace, webhook, ecommerce Friday afternoon, the shop has exactly one speaker left. At the same moment a customer buys it on the website, another confirms an order on a marketplace, and the person at the counter hands the last one to someone standing right there. Three orders, one speaker. Two customers will get "sorry, out of stock", and one of them will leave a one star review. This is stock mismatch, and it shows up in almost every shop that sells in more than one place. This post explains why it happens, the ways to handle it from manual to automatic, and where to start. ## Why stock goes out of sync ![One master stock linked to website, marketplace and spreadsheet](https://phatdev.net/uploads/blog/sync-inventory-web-marketplace/sync-1920.webp) The root is simple: the same stock number is written in several places. The website has one, each marketplace has one, the warehouse spreadsheet has one, the point of sale software has one. Each only updates when a person or a system tells it to. Imagine four notebooks recording the same warehouse, each kept by a different person. When an item sells and is written in one notebook, the other three still show the old number until someone copies it over. That waiting time is when double selling happens. Besides delay, there are a few common causes. An order is cancelled or returned but the stock is never added back. Items sitting in a cart or an unpaid order count as reserved in one place and not in another. The warehouse receives new goods and forgets to update the marketplace. Two people edit the same spreadsheet and overwrite each other. Product codes are named differently in each place, so matching goes wrong. ## Ways to handle it, from manual to automatic ### Way 1: By hand, on a schedule Every morning and afternoon, one person compares stock across the places and fixes it manually. This suits a shop with a few dozen products and a few orders a day. It is cheap and needs no technical skill, but it depends on someone remembering, and there is still a gap between two rounds. ### Way 2: One master file, periodic import and export Pick one place as the master (often a spreadsheet or the warehouse software). The other places receive numbers from it through CSV or Excel imports, a few times a day. Most web platforms and marketplaces have a bulk stock import by file. You type less and make fewer mistakes, but there is still a delay, and someone still has to click. ### Way 3: A scheduled program A small program runs every few minutes: it reads the numbers from the master, compares them with each place, and updates whatever differs. It can read directly from the file or the database of the warehouse software. The delay drops to a few minutes and nobody has to remember. ### Way 4: Connect through APIs and listen for events An API is how two programs talk to each other without a person in between. Most large marketplaces have a developer platform, for example [Shopee Open Platform](https://open.shopee.com/), [Lazada Open Platform](https://open.lazada.com/) and [TikTok Shop Partner Center](https://partner.tiktokshop.com/). Online store platforms have APIs too, such as the [WooCommerce REST API](https://woocommerce.github.io/woocommerce-rest-api-docs/). With an API connection your system can do two things: push the new stock number to the marketplace as soon as it changes, and receive a notification (often called a webhook) whenever a new order arrives so it can reduce stock. The delay shrinks to seconds or a few minutes. Some things to know in advance, since each marketplace differs and can change over time: you usually need to register a developer account and get approved, each platform has its own way of authenticating, there are limits on how often you can call, and the documentation changes. I do not list specific function names here, because one wrong detail does harm; read the official documentation of the marketplace you use, or ask a developer to read it with you. ### Way 5: Use an existing tool Some multi channel selling tools do the syncing for you. The upside is speed and no programming. The downside is a monthly fee, and it does not always match how your shop works. If your process is fairly standard, this is often the most sensible choice. ## Where to start First, choose **one** place to be the master. Every big change (receiving goods, stock counts) is recorded there and the other places are copies. If you cannot choose, mismatch is guaranteed. Then measure the scale: how many products, how many channels, how many orders a day, whether goods sell fast or slow. A shop with few orders and slow sellers is fine with way 1 or 2. Fast sellers, rare items, or many orders at peak hours is when way 3 or 4 starts to pay off. One cheap trick that helps with every way: keep a safety buffer. If the warehouse has 3 units, show only 1 or 2 on the marketplace. When a sync is late, you still have cushion instead of a double sale. ## Common mistakes when automating Some shops connect the website and the marketplace in both directions with no master. The two sides keep overwriting each other and the numbers jump around. Always have one main direction. Some update stock but forget to count orders awaiting payment, so a product shows as available while it is already held. Some run automation with no log. When the numbers drift, nobody knows when or where it started. Record every update: time, product, old number, new number, source. And some switch on without trying real goods first. Test with a few products, compare by hand with reality for a few days, then widen. ## For those who write code A few rules developers should keep. Make each update safe to repeat (calling it twice gives the same result), because networks fail and you will retry. Update with the absolute number from the master instead of "subtract 1", so a missed beat does not leave the count wrong forever. Respect each marketplace's call limits and wait before retrying. Reconcile everything once a night to catch mismatches that events missed. The caching and delay side shares ideas with [Make Your API Faster With Redis: Save Answers So the Database Gets a Break](https://phatdev.net/en/blog/redis-cache-aside-api), and designing an API that is safe to call again is covered in [Designing an API Other People Will Use: Errors, Paging, Safe Retries and Limits](https://phatdev.net/en/blog/rest-api-design-practical). ## What to do next This week, do one small thing: write down every place that stores stock, who updates it, and when. That table alone shows where the mismatch starts. Then pick a master, turn on a safety buffer, and decide which way fits your scale. If your shop already sells in several places and you want to automate, contact me through phatdev.net and include the list of channels you sell on. I will tell you which approach is worth doing and which is not needed yet. ## References - [Shopee Open Platform](https://open.shopee.com/) - [Lazada Open Platform](https://open.lazada.com/) - [TikTok Shop Partner Center](https://partner.tiktokshop.com/) - [WooCommerce REST API documentation](https://woocommerce.github.io/woocommerce-rest-api-docs/) ## Related posts - [Designing an API Other People Will Use: Errors, Paging, Safe Retries and Limits](https://phatdev.net/en/blog/rest-api-design-practical.md) - [Make Your API Faster With Redis: Save Answers So the Database Gets a Break](https://phatdev.net/en/blog/redis-cache-aside-api.md) - [Your First API with FastAPI: Products, Input Checks and Automatic Docs](https://phatdev.net/en/blog/python-fastapi-first-api.md)