On Monday morning, AliExpress store A and Shopee store B shared the same SKU pool. The sync script finished with all logs green, and every API call returned 200. It wasn't until the afternoon reconciliation that store B was found to have 17 more sellable units than the warehouse actually held. No pop-ups, no error codes—just a discrepancy sitting there. This kind of "API returns no error but the numbers don't match" scenario is, at its core, a silent failure: the issue is hidden across four independent layers, and you work outward from data fields to the execution environment, needing just one criterion per layer to pinpoint the cause.
API 200 ≠ Correct Data: Where the 4 Layers of Silent Failure Sit
The four layers, from inside to out:Field mappingDetermines whether the value being written is actually the same number,Race conditionsDetermines which of two writes overwrites the other,Platform RulesDetermines "how much the platform deducted and never returned",Tools and EnvironmentDetermines "whether polling is fast enough and whether the data source is correct." When troubleshooting, start from the first layer; spend 10 minutes on a minimal check at each layer and stop as soon as a match is found—avoid scanning all logs.
First Layer: Field Mapping and Precision
- Variant dimensions misaligned:AliExpress SKU codes include Color + Size + Packaging, while Shopee only captures Color + Size. If a sync script writes the full code as the primary key into Shopee, the same physical item gets split into two records and inventory is double-counted. Check: take a three-variant SKU, compare fields one by one against the mapping table in both platforms' backends, and confirm the dimension sets match exactly.
- Integer vs. Float:Some platform APIs return "quantity": 5.0. If the script stores it directly as a float and then compares it against a local integer ledger, floating-point precision will introduce a 0.001-level deviation after 10 accumulations, causing the reconciliation tool to flag a mismatch. Check: before writing, add a layer of
Math.round()or force an integer field on the platform side, then run a full comparison to see whether the deviation drops to zero. - SKU ID truncation or misalignment:When an auto-increment ID grows from 7 digits to 8, if a downstream script receives it as a fixed-width string, leading zeros are swallowed, causing Store A's ID to land in Store B's slot. Check: sample the last 200 sync logs and verify that the ID field length is constant.
Layer Two: Timing and Race Conditions
The polling interval is 5 minutes, but Shopee completed a stock deduction for an order between two polls while AliExpress simultaneously triggered a restock write. The time gap between the two writes reaching the platform was only 1.2 seconds, and the later one overwrote the earlier result. Both requests returned 200 in the logs, yet the final state matched neither party's expected value. Cache TTL widened this window further: Shopee product pages carry a 60-second CDN cache on stock, so even after a successful API write, the buyer still sees the stale value. The seller, assuming the sync didn't take effect, manually corrects it again, amplifying the discrepancy. Audit your cron or Webhook configuration, reduce the polling interval below the write frequency, and add optimistic lock version numbers to writes on critical SKUs to eliminate most race conditions.
Third Layer: Platform Rules
Local ledger shows 100 units; the platform displays 83 units. The 17-unit gap is not necessarily a loss—it may be that the platform's internal stock sub-status has not flowed back to the sync API:
- AliExpress:After a buyer places an order, stock enters a "reserved" state and is released only if payment is not received within 24 hours. During the reserved period, the sync API returns only "available stock"; the reserved portion is invisible. If a script treats available stock as the total and writes it back locally, the local number will suddenly jump up when the reservation is released.
- Shopee:Promotional stock (flash sale allocations) and regular stock are managed in separate buckets. Deductions during a promotion are not reflected in the API return value of the regular bucket. See the invalidation chain when stock is occupied cross-store under Shopee multi-store fulfillment rules.
- Lazada:Presale inventory is counted separately and is automatically transferred to the regular bucket once the sale begins, but the transfer has a 15-minute delay. Within that delay window, the sync script still reads the presale value.
Criterion: Take separate screenshots of the four sub-items in the platform backend — "Available / Reserved / Campaign Reserved / Presale" — and align them item by item against the local ledger. Whichever sub-item the discrepancy falls under corresponds to a specific platform rule, not a sync bug. For the permission-segmentation logic across multi-platform inventory and orders, refer to the AliExpress Multi-Store Inventory, Order, and Customer Service Permission Segregation article's field design.
Fourth Layer: Tools and Environment
If residual issues remain after fixing the first three layers, the problem most likely lies at the tools layer: polling frequency is below order peak, data sources still rely on manual Excel exports, or multi-store login environments are not isolated, causing cookie cross-contamination. To decide whether to upgrade tools, watch for three signals:manual reconciliation frequency exceeds 3 times per week, cross-platform count exceeds 3, team members simultaneously managing inventory exceed 4. Hitting two or more of these, the maintenance cost of building your own scripts already exceeds the marginal benefit of adopting a unified workspace. In terms of selection, a lightweight SaaS for 2–3 platforms can cover polling and basic reconciliation; only when you have 4 or more platforms or need to consolidate inventory-order-customer service into a single stream should you consider a unified workspace for centralized processing of multi-platform orders, inventory, and messages. For a comparison of tool capability boundaries and selection across the three team tiers, see Multi-Store Operations Tool Selection: Self-Built Spreadsheets, Browser Multi-Tabbing, and Unified Workspaces.
Frequently Asked Questions
After the sync script finishes, how long before you can confirm the platform-side changes have taken effect?
Inventory writes on AliExpress and Lazada are asynchronous—an API returning 200 only means the request was accepted, with an actual write latency of 30–90 seconds. Shopee is relatively faster, at about 15 seconds. To confirm, don't re-query the API; instead, go to the product page (after the CDN cache expires) and check the buyer-facing numbers, or wait for an entry in the platform's backend inventory change log.
If the discrepancy only appears on a single SKU rather than across the board, which layer should you check first?
A single-SKU discrepancy has a 90% probability of being at the first layer (variant mapping or ID misalignment for that SKU) or the third layer (that SKU is in a pre-sale / promotional inventory bucket). Check the mapping table and platform sub-status first, then consider timing.
How do I recover old discrepancies after switching tools?
Don't just do a full overwrite. Run a read-only reconciliation first with the new tool, export the variance list, and confirm the source of each difference per SKU (platform hold vs. true loss), then write back in batches. A full overwrite will clobber the correct numbers.
Will cutting the polling interval down to 10 seconds trigger platform rate limits?
The AliExpress Open Platform caps the per-store inventory API QPS at 5, and Shopee at 10. A 10-second interval won't hit the cap across 3 platforms, but for 4 or more platforms, switch to Webhooks instead of polling, or stagger each store's polling start to avoid concurrent requests in the same second.
If a 3-person team is editing inventory at the same time, do you need an approval workflow?
With 3 people and operations concentrated within 2 platforms, the tool's built-in operation log plus end-of-day reconciliation is enough—no need for an approval workflow. However, once operators exceed 4 or operations span 3 or more platforms, add a dual-confirmation step for the two actions "reduce stock to 0" and "cross-store transfer" to prevent race conditions from compounding with manual overrides. For specific role breakdowns, see Team Multi-Store Role Division and Approval Workflows.
