Stock synchronization breaks at peak sales
The problem is almost never in the storefront itself — it's that the supplier's stock reaches it with a delay and in incomplete form. The supplier provides an export once an hour or once a day, and between exports sales keep going.
Peak sales make everything worse: the higher the order frequency, the faster the accumulated stock discrepancy turns into a sale of an out-of-stock item.
Dropshipping adds a second layer — kits. The goods in the supplier's warehouse are stored as components, while the storefront sells them as a set: one item runs out, but the storefront keeps counting the set as available.
If stock synchronization doesn't expand the kit's composition into individual items, the discrepancy surfaces at the order confirmation stage, when the customer is waiting for delivery.
The third source is the exchange protocol itself. A bulk catalog export and point changes to price and availability travel through different channels, and the order in which they are applied is not guaranteed. An outdated record can overwrite a fresh one and return an already sold-out item to the storefront.
The cost of such a failure is not just a canceled order. It's manual reconciliations, returns, the store's reputation, and lost sales on the most expensive traffic.
Next we'll break down how to build the exchange so that the storefront sees the supplier's real stock, not yesterday's snapshot.
What managed stock synchronization delivers
Managed stock synchronization is not "scheduled file exchange" but a loop where the supplier's warehouse, your catalog, and placed orders converge into a single picture.
When stock updates with a delay, the buyer orders an item that is already gone, and the order is canceled at the picking stage — the share of such cancellations grows along with the assortment and the number of suppliers.
We build the exchange so that stock freshness is maintained at a level where availability in the catalog matches the real warehouse.
The key metric here is the reaction time to a warehouse change: how long it takes from an item being written off at the supplier to it disappearing or being marked "backorder" on your side.
The second indicator is availability accuracy: the share of items where the stated quantity matches the actual one. The third is the volume of manual edits: how many lines managers fix by hand after each reconciliation.
These three values are connected: the shorter the reaction and the higher the accuracy, the fewer manual edits and cancellations due to "out of stock."
We separate two streams — frequent stock updates and infrequent changes to product cards, prices, and supply terms — so that cheap checks don't drag heavy ones along.
Conflicts are resolved by source priority: the supplier's warehouse overrides your catalog stock, but does not overwrite an already placed order. This is how managed stock synchronization turns availability from an approximate estimate into a working value that sales can rely on.
Ways to get data on supplier stock availability
The exchange method determines how quickly a change in a supplier's stock availability reaches your storefront. Below are four working options that are realistically chosen between when integrating with a dropshipping supplier.
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled files (CSV/XLS) | The supplier provides a price list as an export, the SKU volume is stable, a delay of hours is acceptable | Availability becomes stale between exports; discrepancies in format and encoding break parsing; there are no "item went to zero" events |
| Requests to the supplier's interface | You need minute-level freshness, the supplier provides programmatic access to stock levels | It hits request limits; when checking the catalog in bulk, some items are checked with a delay |
| Event stream | The supplier itself reports stock changes | It requires a stable channel and handling of duplicates; if the connection drops, reconciliation is needed, otherwise events are lost |
| Manual export | One-off purchases, a trial period, a small assortment | It does not scale: an operator cannot keep up with the frequency of changes, and input errors are inevitable |
In practice, they are most often combined: an event stream for fast-moving items and periodic reconciliation of the full catalog to catch missed updates.
The update frequency is chosen to match the product — for fast-turning categories, once every few minutes; for the rest, once an hour is enough.
Separately, it is worth thinking through what to do in case of desynchronization: if the supplier has provided a stock level but the order has already been placed, the item should go into reserve rather than be sold twice. This is already a matter of data acceptance logic, not channel choice — we'll cover it next.
How we build stock balance exchange
Stock balance exchange is not "a single integration" but an ongoing process: the supplier changes the export format, new warehouses appear, some items go into reserve.
We start with an inventory of sources and finish with a regulation according to which your team maintains the exchange without us.
- Source analysis. We collect all the places where data comes from: file exports, scheduled exchange, the supplier's personal account. We record the update frequency, time zone, behavior when an item is out of stock, and how the supplier marks reserve and expected incoming stock.
- Exchange scheme. We determine the direction of flows, the polling period, and the window within which data must reach the catalog. We build in idempotency: a repeated run must not duplicate items or zero out the balance.
- Matching rules. We map the supplier's SKUs to your nomenclature: by code, barcode, "brand + model" combination. We separately describe what to do with new items and with products the supplier has discontinued.
- Discrepancy handling. Negative balances, quantity spikes, items without a price — each case gets a rule: zero out, keep the previous value, or send to a queue for manual review.
- Testing on historical data. We run the rules on past exports and compare the result with what was actually in the catalog. This shows how many items would have gone into error before launch.
- Launch and monitoring. We enable the exchange, monitor the share of successful cycles and the time from receiving data to updating the card. Errors are not lost — they go into a log with the reason.
- Handover of the regulation. We provide the description of flows, matching rules, and the procedure for failures, so that support can handle typical cases on their own.
After launch, the exchange lives its own life: the supplier changes the format, and the regulation suggests where to make edits. Describe which suppliers you work with — we will come back with an estimate and a plan.
Rules for product matching and protection against desync
Desync almost always starts not on the supplier's side, but at the junction of two catalogs: they have the SKU ABC-01-BLK, we have ABC01BLK, and both "exist", but the stock for them lives separately.
That is why we set up SKU matching as a separate layer with explicit rules, rather than as a one-time price list upload.
- Matching key — the combination of "supplier SKU + manufacturer code", not the name: text matching breaks on spaces, case, and Cyrillic-Latin. For items without a common code, we maintain a table of manual mappings, which the rule does not overwrite on the next import.
- Kits and sets — we calculate the stock of the parent item as the minimum across components, not as a separate number. Otherwise we sell a set that does not exist, or block a sale when all the parts are in stock.
- Regional warehouses — we store stock broken down by warehouse, and to the storefront we serve the sum across available delivery zones. A single shared counter results in a sale from a region the goods will not ship from.
- Buffer stock — we keep a reserve at each warehouse so that an order does not go negative between two updates. We select the amount based on the item's sales velocity, not a single figure for the entire catalog.
- Protection against desync — an update does not overwrite stock with zero when the supplier's response is empty or corrupted. We mark such an update as suspicious, keep the previous values, and investigate it manually.
- Change log — for each item it is visible who changed the stock and when: a rule, a manual edit, or a supplier's response. Without it, an incident is not investigated but guessed at.
- Discrepancy threshold — if the stock changed by more than a set share in a single update, the rule stops the write and raises an alert. A mass zeroing of the catalog is caught before it reaches the storefront.
Such a set of rules eliminates phantom stock at the root: the storefront shows what is actually in the warehouse and can be shipped.
What the client receives after implementation
Implementation is considered complete not at the moment the exchange starts working, but when your team can maintain it without us.
That is why the final package is not "access credentials and a couple of screenshots," but a set of artifacts by which any engineer will understand how inventory synchronization is structured and what to do when there is a deviation.
- Exchange diagram — which systems are involved, who initiates the request, how often polling occurs, what happens when the supplier is unavailable, and how the retry queue is structured.
- Processing rules — how items are matched by SKU and barcode, what to do with unmatched positions, how conflicts are resolved when the supplier returns inventory later than your sale.
- Discrepancy log — accumulation of cases where the supplier's data diverged from actual data: incorrect SKU, zero inventory when the item is in stock, duplicate positions. The log is kept with history so you can see who has a systemic problem and where it was a one-off failure.
- Response regulations — thresholds at which the exchange stops automatically, who receives the notification, and within what timeframe the position returns to sale after manual verification.
- Team instructions — step-by-step scenarios for typical situations: the supplier changed the export format, inventory was mass-reset to zero, the queue hung. With an indication of what to check first.
- Monitoring and alerts — which metrics are collected, where to check the freshness of the last exchange, and how to distinguish a supplier delay from a failure on our side.
- Handover of maintenance — a joint walkthrough of the diagram with your engineers, answers to questions about the code and settings, and a period when we are available in parallel with your team.
Each item is a working document, not a description "for the checkbox": with it, you can bring the exchange back up after a failure, connect a new supplier, or hand the task over to another contractor. If any questions remain about any artifact, we refine it before we close the project.
How does scheduled export differ from an event stream?
Scheduled export is exchange on a schedule: every N minutes the application pulls a full or incremental snapshot of stock from the supplier and overwrites the storefront.
The update delay here equals the polling interval plus the time of the export itself, and it is predictable: if the supplier returns the catalog in 40 seconds and polling runs every 15 minutes, the buyer sees stock lagging by up to 16 minutes.
The load on the storefront is even — one bulk pass instead of thousands of small changes, so this mode is cheaper to maintain and easier to debug.
An event stream works differently: the supplier itself reports a change — a delivery arrived, the last unit left, a reservation was canceled — and we apply each change the moment it appears.
The delay drops to seconds, but the load on the storefront becomes uneven: at the moment of a bulk goods receipt, hundreds of events arrive in a row, and without a queue, deduplication, and protection against redelivery, the storefront starts to "jitter" — stock bounces back and forth, and the buyer sees either availability or a refusal.
The choice is dictated not by fashion but by the cost of an error. If an item is fast-moving and sells out within minutes, scheduled export is guaranteed to sell what is not there: the order goes to cancellation, and support handles the returns.
If an item sits for weeks, an event stream is unnecessary complexity: a queue, retries, and reconciliation of discrepancies will cost more than infrequent polling.
In practice, it is most often a hybrid: an event stream for critical categories and fast polling for the rest of the catalog, plus a nightly reconciliation of the full snapshot that catches everything lost in the events.
This is the contour we build for stock synchronization with a dropshipping supplier — with a log of applied changes, so that a discrepancy can be rolled back to a specific event rather than rebuilding the storefront entirely.
Case study: eliminating cancellations caused by stale stock data
The client is a retail store working with several dropshipping suppliers via OpenCart. Orders were accepted on the website, while stock availability was pulled in through a nightly export file: up to 12 hours passed between updates.
During that window, managers managed to sell items that were no longer in the supplier's warehouse — the share of cancelled orders held at 9%, and each cancellation dragged along a refund, correspondence with the customer, and a manual status correction.
What it was like before the rebuild
The exchange ran as one large file once a day, with no breakdown by supplier. If one of them delayed the export, the entire catalog suffered: stock levels for that supplier remained "frozen" at outdated values.
Discrepancies between the website and the actual warehouse reached 14% for fast-moving items, and managers spent an average of 6 minutes manually reconciling each disputed order.
What was changed
The exchange was split into independent streams per supplier and switched to regular polling at a 15-minute interval instead of a daily export.
A rule was added: if a supplier does not respond for longer than two cycles, its items automatically go into reserve with an "being verified" mark rather than being sold on old data.
A discrepancy log was introduced — every stock adjustment is recorded with its source and time, so it became clear which supplier produces the most failures.
What the result was
The share of cancelled orders dropped from 9% to 1.8%, and stock discrepancies — from 14% to 2%. The reaction time to a stock change was reduced from 12 hours to 15 minutes, and manual status corrections — from 40–50 per week to isolated cases.
Managers stopped reconciling every disputed order by hand: the system itself flags items for which there is no fresh confirmation.
Common technical concerns
Concerns about synchronization usually come down to three things: how the system behaves with multiple suppliers, whether it can be integrated into an already running storefront, and what happens when the communication channel to a supplier drops in the middle of the day. Below are answers to what most often comes up during the evaluation stage.
We have several suppliers — won't the stock levels conflict with each other?
No, if each product is tied to a specific source rather than a shared pool.
We create a separate account for each supplier, match their SKUs with the storefront's product cards, and maintain source priority: if an item is available from two suppliers, the sale goes to the one whose stock is fresher and more reliable. Conflicts are resolved by the priority rule, not by manual editing.
We already have a storefront deployed — will we have to rebuild it?
In most cases, no. We connect to the existing product and order database through the standard software interface, without touching the layout or the checkout logic.
Only the layer that receives stock levels and passes them to the storefront changes: we add SKU matching, the priority rule, and a change log. If the catalog structure is non-standard, we agree on the matching scheme before work begins.
What happens if the connection to a supplier is lost?
A fallback mode kicks in. The system does not zero out stock levels or take products off sale — it marks the data as outdated and continues working on the last confirmed snapshot.
When the channel comes back, the changes are caught up, and discrepancies on items sold during the outage go into a report. This way the storefront doesn't "flicker" and the customer doesn't see a product that isn't there.
How do we know that synchronization is actually working correctly?
We keep an exchange log and reconciliation: how many items were updated, how many were discarded as incorrect, where the stock level diverged from the source. From this data, bottlenecks become visible before they turn into canceled orders. We surface the data freshness metric prominently so that any deviation is noticeable immediately.
Describe your supplier scheme and current storefront — we'll come back with an assessment and an integration plan.
Let's discuss your stock balance exchange scheme
To come back with an estimate and an implementation plan, we need your current stock balance exchange scheme — as is, without polishing.
Based on it, we calculate the scope of work and show exactly where synchronization breaks: discrepancies across warehouses, the delay between write-off and update, duplicate items during parallel orders.
Send whatever you have on hand — that's enough for a substantive conversation:
- list of suppliers and the method of data retrieval: file export, scheduled exchange, change notifications;
- how often stock balances are updated now and what happens at zero stock — is the item taken off sale or does it go negative;
- where the product catalog is stored and how supplier SKUs are matched with yours;
- what's already breaking: stuck orders, manual stock adjustments, complaints about "the item is in stock, but it isn't there";
- which systems are involved in the chain — website, accounting system, warehouse, delivery service;
- supplier constraints: request rate limits, response formats, available authorization methods;
- who on the business side makes decisions on disputed items and priority rules.
From this picture, we assemble an implementation plan: the order in which suppliers are connected, rules for resolving conflicts between sources, the reconciliation mode, and control points.
The work estimate is based on the real scope, not on average market figures, so an "as is" scheme saves both your time and ours.
Describe the task in whatever form is convenient — messages, a document, screenshots of settings. We'll come back with an estimate and a work plan, and we'll go over the disputed points on a call with your engineer.
