Building on Amazon SP-API: What No One Tells You About Marketplace Automation

Amazon's Selling Partner API is powerful and genuinely complex. After building a platform that synced 50k+ SKUs across 5 Amazon marketplaces, here's everything I wish I'd known before starting.

The auth story nobody explains clearly

SP-API uses Login with Amazon (LWA) — not IAM, not Cognito. You need an LWA client ID and secret, a refresh token per seller, and an IAM role with specific SP-API permissions. The LWA access token expires in 1 hour. Build your auth layer to refresh proactively, not reactively — retrying a failed request on token expiry burns your rate limit quota.

Rate limits are per-plan, per-endpoint

Every SP-API operation has its own rate limit plan: a burst rate and a restore rate. The Listings API has different limits than the Orders API, which has different limits than the Reports API. You cannot treat SP-API like a single bucket. Model each endpoint's rate limit independently with a token bucket algorithm. Exceeding limits returns HTTP 429, which counts against you.

The sandbox is not production

The SP-API sandbox uses static test data and doesn't reflect real marketplace behaviour. Sandbox accepts calls that production will reject. Always test auth flows, webhook delivery, and edge-case SKU data in production with a test seller account before going live with real inventory.

Inventory sync: don't poll, stream

Polling the Catalog Items API for 50k SKUs every 15 minutes is how you get throttled into oblivion. The right architecture: use the Notifications API to subscribe to ITEM_INVENTORY_UPDATE events, pipe them into SQS, and process asynchronously via Lambda. Each Lambda processes a batch of SKU changes, not a full catalogue scan. This cut our sync latency from 24 hours to under 15 minutes while using 90% fewer API calls.

The repricing engine

The Buy Box is won by price, fulfilment method, and seller metrics — in that order for most categories. Build your repricing engine to: (1) pull competitor prices from the Competitive Pricing API, (2) apply your floor/ceiling rules, (3) submit price changes via the Listings API in batches of 10 (max per request). Run this every 15 minutes on an EventBridge schedule. Faster than that and you risk looking like a bot to Amazon's fraud detection.