Amazon, Shopify and eBay Unified Inventory in Your ERP in 2026: Middleware Architecture

Unifying Amazon, Shopify, and eBay inventory into a single ERP (SAP Business One, NetSuite, Odoo, Acumatica) costs $18,000–75,000 in 2026. The range depends on SKU volume, order volume, ERP, and how many marketplaces you're integrating. The architecture that works is a middleware layer — not point-to-point integrations. A message bus (RabbitMQ or AWS SQS) connects marketplace webhooks to idempotent ERP write handlers. The alternative — direct integrations from each marketplace to the ERP — fails at scale due to race conditions, API limits, and maintainability.

This guide explains the middleware architecture, the specific challenges of each marketplace API, and how to size the project.

Why Point-to-Point Fails

Point-to-point means: marketplace A writes directly to ERP, marketplace B writes directly to ERP, marketplace C writes directly to ERP. Three problems:

Race conditions on inventory decrement. If Amazon and eBay both have the last unit of SKU-123 in a customer's cart at the same moment, both fire order webhooks within milliseconds. Your ERP receives two decrements for the same unit. Without idempotent handlers and optimistic locking, you oversell.

API rate limits compound. Amazon SP-API has throttling limits per endpoint. Shopify has limits at 2 requests/second per store. eBay's Trading API has daily call limits. When your three marketplaces all peak simultaneously (holiday season), direct integrations hit rate limits and fail silently — orders queue up but don't post to ERP.

Every new marketplace multiplies integration debt. Add Walmart Marketplace: you now need a direct connection to ERP. Add TikTok Shop: another one. With middleware, you add a single adapter per new marketplace; the ERP layer doesn't change.

The Middleware Architecture

The correct model:

[Amazon SP-API webhook]  ─┐
[Shopify webhook]         ├─→ [Message Bus: SQS/RabbitMQ] → [Idempotent Handler] → [ERP]
[eBay webhook]           ─┘
                                                             [Reconciliation Job] → [ERP]

Message bus (AWS SQS or RabbitMQ): receives webhook payloads from all marketplaces, stores them durably, and delivers them to handlers exactly-once (SQS FIFO queue) or at-least-once with deduplication.

Idempotent handler: before writing to ERP, checks if this order ID has already been processed. If yes, skips. If no, processes and marks as done. This is the core protection against double-processing from duplicate webhooks.

Inventory reservation pattern: when an order arrives, the handler decrements inventory in a "reserved" column rather than "available" column. A separate fulfillment step moves from "reserved" to "shipped" and syncs back to all marketplaces. This prevents the race condition: if two orders arrive for the last unit, the second finds zero "available" inventory and is rejected or queued for manual review.

Reconciliation job: runs every 15–60 minutes (configurable). Pulls actual inventory from ERP, computes the delta versus what each marketplace shows, and pushes corrections. This is the safety net for webhook failures, API outages, and edge cases the idempotent handler misses.

Amazon SP-API Specifics

Amazon's Selling Partner API replaced MWS in 2022. Key characteristics for integration:

Inventory: use Inventory Ledger, not just Listings. The getInventorySummaries endpoint gives current counts but doesn't give you a ledger of changes. For reconciliation, subscribe to the AnyOfferChanged, FBAInventoryAvailability, and InventoryHealth notification types.

Rate limits are per-operation, not per-account. Each SP-API operation has its own rate limit (e.g., getOrders is 0.0167 requests/second). Design your handlers to respect burst rates using a token bucket algorithm.

Throttling without retry-after header. Amazon SP-API returns HTTP 429 without a Retry-After header. Implement exponential backoff with jitter (start at 1 second, cap at 60 seconds).

FBA vs FBM inventory are different. FBA (Fulfilled by Amazon) inventory lives in Amazon's warehouses and depletes separately from your own warehouse inventory. Your middleware must track FBA vs FBM counts separately and sync each appropriately.

Shopify Rate Limits and Large Catalogs

REST API: 2 requests/second per store (burst to 40 with leaky bucket). GraphQL API: 50 cost units/second (operations vary from 1 to 100 cost units). For large catalogs (10K+ SKUs), use GraphQL bulk operations — a single async job exports all inventory data without hitting rate limits.

Webhooks are best-effort. Shopify guarantees delivery but can delay or miss webhooks during their infrastructure incidents (rare, but it happens). Your reconciliation job is the guaranteed sync path. Webhook is the fast path (sub-second), reconciliation is the reliable path (every 30 minutes).

Shopify's inventory_item_id vs variant_id vs product_id. Integration confusion here causes bugs. Inventory quantities are tracked at InventoryItem level (not Product). Your ERP mapping must use inventory_item_id as the canonical identifier, not SKU (which can be non-unique across products).

eBay Sync Latency and Trading API

eBay's inventory ecosystem has two layers: the older Trading API (still widely used) and the newer Inventory API (more modern but not fully adopted by sellers).

eBay sync latency is 2–5 minutes minimum. Unlike Amazon (near-real-time) and Shopify (real-time webhooks), eBay's inventory updates propagate in minutes. For low-volume sellers, this is fine. For sellers doing 500+ orders/day, a 5-minute lag means manual stock adjustments between marketplace refreshes.

Trading API daily call limits. The application-level call limit is 5,000–15,000 calls/day depending on your seller tier. A reconciliation job running every 5 minutes consumes 288 calls/day just for pulling inventory — well within limits. But error retries on a bad day can approach the limit.

eBay Notifications (not webhooks). eBay uses an XML notification system, not HTTP webhooks. You configure a listener URL; eBay sends XML POST to that URL for order and inventory events. Your middleware must parse eBay's XML format (not JSON like Amazon/Shopify), which adds a parsing layer.

ERP Target Comparison

ERP	Best for	Middleware approach	Integration cost
SAP Business One	Mid-market, 50–500 employees	SAP B1 DI API or Service Layer	$20K–50K middleware
NetSuite	Growing e-commerce, SuiteScript	REST Record API + SuiteScript triggers	$25K–65K middleware
Odoo	Open-source, flexibility	Odoo JSON-RPC or REST	$15K–40K middleware
Acumatica	US mid-market	Acumatica OData REST API	$18K–45K middleware

NetSuite built-in connectors: NetSuite offers a native "SuiteCommerce Advanced" and various App Center connectors for Shopify. For Amazon + eBay + Shopify together, these connectors rarely handle all three cleanly — they're built for Shopify-primary setups. Custom middleware still wins for tri-marketplace scenarios.

Real 2026 Pricing

Starter ($18,000–30,000): 2 marketplaces (Shopify + Amazon), 1 ERP, up to 5,000 SKUs, basic idempotency, reconciliation every 60 min, 24h SLA for critical issues. Build: 8–14 weeks.

Standard ($32,000–55,000): 3 marketplaces (+ eBay), 1 ERP, up to 50,000 SKUs, full inventory reservation pattern, reconciliation every 15 min, FBA/FBM split, advanced alerting. Build: 14–22 weeks.

Enterprise ($60,000–75,000+): 4+ marketplaces, multiple ERPs or warehouse systems, 100K+ SKUs, real-time dashboard, custom reconciliation logic, 99.9% SLA. Build: 22–32 weeks.

Infrastructure: $400–1,500/month (message bus, compute, monitoring, storage).

Observability: Not Optional

The most common integration failure mode is silent. Orders stop posting to ERP, no error is thrown, no alert fires — until operations notices a manual count discrepancy three days later.

Minimum observability:

• Message queue depth alert: if SQS queue depth exceeds 1,000 messages for 5+ minutes, something is broken
• Order processing latency alert: if time from webhook to ERP write exceeds 5 minutes, page someone
• Reconciliation delta alert: if reconciliation job finds more than 50 units of discrepancy across any SKU, investigate
• Dead letter queue monitoring: all unprocessable messages go to DLQ; DLQ non-empty should page on-call

FAQ

Can I skip middleware and use Zapier? Zapier works for order notification at low volume (under 100 orders/month). It breaks above that: rate limits, no real idempotency, no retry logic, no reconciliation. Zapier is a no-code tool; this is an engineering problem.

How do I handle inventory race conditions across 3 marketplaces? Inventory reservation pattern: when order comes in, decrement "reserved" not "available". Second order for same unit finds "available" = 0 and is rejected. Fulfillment moves units from "reserved" to "shipped" and syncs to all marketplaces. This requires a database write to happen before the ERP write — order of operations matters.

Can I use NetSuite's built-in Shopify connector and custom for Amazon/eBay? Yes, hybrid approaches work. NetSuite handles Shopify natively; your custom middleware handles Amazon + eBay. The challenge: you need unified reconciliation across both systems. A single reconciliation job that pulls from NetSuite and compares against all three marketplaces is still the cleanest architecture.

What happens when eBay is down for 3 hours? If eBay is down, your middleware receives no notifications. Your reconciliation job will run and find stale eBay inventory data. For eBay outages, the reconciliation job should pause eBay updates (not post stale data) and resume when eBay responds normally. Your message bus should log the outage window for audit.

How do I reconcile Amazon fees in ERP? Amazon sends a financial ledger via SP-API (listFinancialEventGroups). Your middleware can parse this into ERP journal entries: COGS debit, Amazon fee expense, receivable credit. This runs daily (Amazon settles every 14 days but ledger data updates daily) and posts automatically to ERP's AP module.

---

Multichannel inventory getting out of hand? Talk to an ERP integration expert on WhatsApp — we scope this in one call and quote within 48 hours.