Marketplace Inventory Sync: A Unified Guide for Amazon, eBay, and Walmart
The Platform-Specific Reality of Marketplace Sync
Most inventory sync guides treat all marketplaces the same: "push your stock count and make sure it is accurate." In reality, Amazon, eBay, and Walmart each have different APIs, different processing behaviors, different rate limits, and different failure modes. A sync strategy that works perfectly for Amazon will cause problems on eBay, and vice versa.
This guide covers the specific sync behavior of each platform and provides a unified architecture that handles all three reliably from a single source of truth.
Amazon SP-API Inventory Sync
How Amazon Processes Inventory Updates
Amazon's Selling Partner API (SP-API) accepts inventory updates in near-real-time, but processes them asynchronously. The key behavior to understand:
Amazon Inventory Update Flow:
1. You push inventory update via SP-API → Immediate (API response in 1–3 sec)
2. Amazon queues the update for processing → 2–5 min typical queue time
3. Amazon applies the update to the listing → 3–10 min after queue
4. Customer sees updated availability → 5–15 min total latency
Critical implication:
Even with "real-time" pushes, Amazon has a 5–15 minute window where
the listed quantity may not reflect your actual stock.
Amazon-Specific Sync Rules
- FBA vs FBM inventory are separate: FBA inventory is managed by Amazon. You can track it but should not try to override it. FBM inventory is fully under your control. Your sync should only update FBM quantities.
- Use the Listings API for inventory updates: The modern SP-API uses the Listings API (not the legacy Feeds API) for inventory quantity updates. Submit updates as JSON patches for faster processing.
- Respect rate limits: SP-API rate limits vary by operation. Inventory updates are throttled to 5 requests per second. For catalogs over 1,000 SKUs, use bulk feed submissions rather than individual API calls.
- Handle multi-marketplace: If you sell on Amazon US, CA, and MX, each marketplace requires separate inventory updates. Ensure your sync system addresses each marketplace independently.
- Buffer recommendation: Minimum 5-unit buffer or 15% of available stock (whichever is larger) to account for the 5–15 minute processing delay.
eBay Inventory Sync
How eBay Processes Inventory Updates
eBay inventory updates process faster than Amazon — typically within 1–3 minutes. However, eBay's inventory model is more complex due to its auction heritage.
eBay-Specific Sync Rules
- Fixed-price vs auction listings: Inventory sync applies only to fixed-price (Good 'Til Cancelled) listings. Auction-format listings have a fixed quantity (usually 1) and cannot be dynamically updated during the auction.
- Multi-variation listings: eBay treats multi-variation listings (e.g., a t-shirt with size and color options) differently from single-SKU listings. Update inventory at the variation level, not the parent listing level.
- Use the Inventory API (not Trading API): eBay's REST-based Inventory API is the modern approach. The older Trading API (ReviseInventoryStatus) still works but has more quirks and slower processing.
- Out-of-stock listing behavior: eBay offers an "Out of Stock" control that hides listings at zero inventory rather than ending them. Enable this to preserve listing history and SEO value. Your sync should set quantity to 0 (not end the listing) when stock runs out.
- Rate limits: eBay's API call limits are per-app and vary by traffic tier. Standard-tier apps get 5,000 calls per day. High-volume sellers can request higher limits.
- Buffer recommendation: 3-unit buffer or 10% of available stock. eBay's faster processing allows smaller buffers than Amazon.
Walmart Marketplace Inventory Sync
How Walmart Processes Inventory Updates
Walmart's Marketplace API processes inventory updates at the item level with moderate latency (3–10 minutes typical).
Walmart-Specific Sync Rules
- Item-level updates: Walmart updates inventory at the individual item level. Each API call updates one item. For large catalogs, use bulk feeds (XML or JSON) for efficiency.
- Fulfillment type matters: Walmart distinguishes between Seller-Fulfilled and Walmart Fulfillment Services (WFS) inventory. Like Amazon FBA, let Walmart manage WFS counts — only sync seller-fulfilled quantities.
- Strict seller scorecard impact: Walmart's On-Time Delivery and Cancellation Rate metrics are heavily penalized for inventory-related order cancellations. Overselling on Walmart carries higher seller account risk than on Amazon or eBay.
- Two-Day delivery tagging: Products eligible for Walmart's Two-Day delivery badge must have inventory at a location that can meet the delivery SLA. Your sync must update inventory per fulfillment node, not just total quantity.
- API authentication: Walmart uses a token-based authentication that expires every 15 minutes. Your sync service must handle token refresh automatically without interrupting inventory updates.
- Buffer recommendation: 5-unit buffer or 12% of available stock. Walmart's strict seller scorecard makes overselling particularly costly on this platform.
The Unified Sync Architecture
Rather than building separate sync systems for each marketplace, use a single architecture with platform-specific adapters.
Unified Architecture:
Source of Truth (ERP/OMS)
│
▼
Inventory Event Bus
│
├──▶ Amazon Adapter ──▶ SP-API (buffer: 15%)
│ └── Rate limiter: 5 req/sec
│ └── Bulk feed for >1000 SKU updates
│
├──▶ eBay Adapter ──▶ Inventory API (buffer: 10%)
│ └── Rate limiter: per-app daily limit
│ └── Variation-level updates
│
├──▶ Walmart Adapter ──▶ Marketplace API (buffer: 12%)
│ └── Token refresh every 15 min
│ └── Item-level or bulk feed
│
└──▶ DTC (Shopify) Adapter ──▶ Inventory Level API (buffer: 5%)
└── Location-level updates
Adapter Responsibilities
Each marketplace adapter handles:
- Buffer calculation: Apply the platform-specific buffer percentage before pushing inventory
- Rate limiting: Throttle requests to stay within platform limits
- Error handling: Retry with exponential backoff on transient failures; alert on persistent failures
- Format translation: Convert your internal inventory event format to the platform's expected API format
- Reconciliation: Periodically pull the marketplace's reported inventory and compare to expected values
Cross-Platform Inventory Allocation
When selling the same SKU on multiple marketplaces, you need allocation rules that prevent any single channel from consuming all available stock.
| Strategy | How It Works | Best For |
|---|---|---|
| Shared pool with buffers | All channels see the same ATP minus platform-specific buffers | Simple catalogs, low SKU count, moderate volume |
| Fixed allocation | Each channel gets a fixed percentage (e.g., Amazon 50%, eBay 25%, Walmart 25%) | Predictable demand, balanced channel strategy |
| Velocity-based allocation | Channels with higher velocity get proportionally more allocation | Data-driven operations, channels with different demand levels |
| Margin-optimized allocation | Higher-margin channels get priority allocation when stock is constrained | Limited inventory, significant margin differences between channels |
Reconciliation Process
No sync pipeline is perfect. Periodic reconciliation catches and corrects drift before it causes overselling.
Reconciliation Schedule
Every 4 hours (automated):
For each marketplace:
1. Pull current inventory from marketplace API
2. Compare to expected inventory (your OMS minus sold orders)
3. If delta > threshold:
- Push corrective update to marketplace
- Log discrepancy with timestamp and delta
- Alert if delta > 10 units or > 5%
Daily (review):
- Review discrepancy log
- Identify patterns (same SKU always drifts on the same platform → investigate root cause)
- Verify reconciliation corrections were applied successfully
Weekly (audit):
- Full inventory comparison across all marketplaces
- Check for "ghost listings" (active marketplace listings for discontinued SKUs)
- Verify new product mappings are syncing correctly
Failure Handling: When Sync Breaks
Every sync system will eventually fail. The question is whether you fail safely (prevent overselling) or dangerously (continue showing stale inventory).
Failure Response Protocol
- Transient failure (single API error): Retry with exponential backoff. First retry after 5 seconds, then 15, then 60. Log each retry.
- Persistent failure (3+ consecutive errors): Alert the operations team. Continue retrying on a slower schedule (every 5 minutes).
- Extended outage (>30 minutes without successful sync): Automatically set inventory to zero on the affected marketplace. This stops sales on that channel until sync recovers, preventing overselling. Lost sales during the outage are preferable to overselling and account penalties.
- Platform API outage: Monitor marketplace status pages. During known API outages, pause sync attempts to avoid rate limit penalties on recovery.
Common Mistakes
- Using the same buffer for all marketplaces: Amazon's 5–15 minute processing delay requires larger buffers than eBay's 1–3 minute processing. Match buffers to each platform's actual update latency.
- Syncing FBA or WFS inventory: These are managed by the marketplace. Attempting to override marketplace-managed inventory creates reconciliation conflicts. Sync only seller-fulfilled quantities.
- Not handling marketplace-side manual adjustments: If someone adjusts inventory in Seller Central, your OMS does not know about it. Subscribe to inventory change notifications where available, and run frequent reconciliation to catch manual changes.
- Ending listings instead of setting quantity to zero: Ending a marketplace listing loses its sales history, reviews, and search ranking. When stock runs out, set quantity to zero and let the platform hide the listing (using out-of-stock controls). Restore quantity when stock is replenished to retain listing equity.
Frequently Asked Questions
Each marketplace processes inventory updates differently. Amazon's SP-API has a 5–15 minute processing delay even for real-time pushes. eBay uses a different inventory model for fixed-price vs auction listings. Walmart requires inventory to be updated at the item level and has strict throttling limits. Using the same sync logic for all three results in platform-specific failures — typically overselling on the platform with the longest update delay.
Use channel-level buffer reserves adjusted for each platform's actual update latency. Amazon needs a larger buffer (5–15 minute update delay) than eBay (near-real-time) or your DTC store. Never show 100% of your stock on any single channel. A simple starting rule: show 85% of available stock on Amazon, 90% on eBay, and 95% on Walmart. Reduce these percentages during high-velocity periods. Always maintain your OMS or ERP as the single source of truth for inventory counts.
If sync fails, the marketplace continues showing the last-known inventory count. For a product with declining stock, this means the marketplace may show units available that have already sold on other channels — leading to overselling. Your sync system should monitor for failures and take automatic action: retry with exponential backoff, and if failures persist beyond a threshold (e.g., 3 consecutive failures), automatically set inventory to zero on the affected marketplace to prevent overselling at the cost of temporarily lost sales.
Keep FBA inventory and your own warehouse inventory as separate pools in your OMS. Amazon manages FBA stock — you should not sync your warehouse counts into FBA quantities or vice versa. Your OMS should track both pools and present a unified available-to-promise for your DTC channels, but let Amazon control FBA quantities independently. The common mistake is trying to unify FBA and warehouse stock into one number, which creates reconciliation nightmares when Amazon's count differs from yours.
Run automated reconciliation every 4 hours at minimum. For each SKU, compare the inventory count your OMS expects the marketplace to show against the count the marketplace actually reports. Any discrepancy beyond a threshold (e.g., more than 2 units or 5% difference) should trigger an automatic correction push and an alert for investigation. Common causes of drift: manual adjustments made in Seller Central/Seller Hub, marketplace-side order processing delays, and returns that increment marketplace inventory before your OMS processes the return.
