Linnworks Amazon Integration UK: How to Set It Up, What Breaks, and How to Fix It
Linnworks connects to Amazon via Amazon's SP-API — a token-authenticated connection that replaces the deprecated MWS API. For most UK merchants, the setup is straightforward: authorise the connection in Linnworks, map your FBA and FBM fulfilment routes, and orders start flowing. The integration handles order download, stock level sync, shipping confirmation, and FBA inventory tracking within one system.
Where it gets complicated is Amazon's side. Amazon enforces rate limits aggressively, and the two main SP-API failure modes — ThrottlingException and AccessDenied — look similar on the surface but have completely different causes and fixes. Mix them up and you'll apply the wrong remedy. There's also a stock pool collision between FBA and FBM lines that generates oversells quietly, a bulk listing feed and Inventory API conflict that surfaces during burst operations, and a legacy MWS migration path for any merchant who set up their Amazon connection before 2024.
This guide covers the full integration: SP-API authentication, FBA versus FBM order routing, the specific failure modes with named fixes, and what to verify before going live. For hands-on help, talk to our Linnworks integration specialists.
What the Linnworks–Amazon Integration Actually Does
- New orders (polling every 5 minutes)
- Order cancellations and status changes
- FBA inventory levels (Fulfilment Inventory API — read-only)
- Buyer shipping address and order details
- FBM stock level updates
- Shipping confirmation and tracking (FBM)
- Bulk listing feed updates (titles, descriptions, price)
- FBM despatch notification trigger
- FBA stock (Amazon manages directly)
- Amazon Advertising data
- Amazon feedback and reviews
- Returns/refunds (manual reinstatement required)
Architecture note: The integration uses SP-API across four role scopes: Selling Partner Insights (orders), Fulfilment Inventory (FBA stock read), Orders (FBM despatch), and Feeds (bulk listing updates). The scope granted at authorisation determines what Linnworks can and cannot do — mismatched permissions are a common source of silent failures.
FBA vs FBM: FBA orders are picked, packed, and shipped by Amazon — Linnworks records the order but does not send shipping confirmation. FBM orders are fulfilled from your warehouse — Linnworks downloads, you despatch, Linnworks pushes tracking back to Amazon. Different workflows, different failure modes. Knowing which type you're diagnosing is always the first step.
Setup: Connecting Linnworks to Amazon UK
Prerequisites: Linnworks Standard or above, Amazon Seller Central on Professional plan, SP-API access enabled. Amazon requires explicit authorisation — you grant Linnworks access via Seller Central's developer app consent flow.
- Linnworks: Settings → Channel Integration → Add Channel → Amazon
- Select marketplace: Amazon.co.uk (not .com — different token scope)
- Click Authorise → Seller Central SP-API consent screen
- Grant Linnworks all four required SP-API role scopes in Seller Central
- Return to Linnworks — channel confirmed
- Assign your warehouse to the FBM channel
- Configure FBA order routing — FBA orders into a separate folder, no despatch action
- Confirm FBM order download rules (default: Unshipped status)
SKU matching: Linnworks maps to Amazon using the Seller SKU — must match your Linnworks item SKU exactly, case-sensitive. For FBA products, ASIN-based matching is also available.
MWS legacy accounts: If your Linnworks Amazon connection predates 2024, it may be running on the deprecated MWS API. The characteristic symptom: orders appearing late with no clear error — present in Seller Central but arriving in Linnworks hours late, with nothing visible in either system's error log. Check Linnworks → Channel Integration → Amazon → connection details to confirm SP-API vs MWS. If MWS: disconnect and re-authorise via SP-API from scratch. Do not try to patch the legacy connection.
SP-API Failures: ThrottlingException vs AccessDenied — Two Distinct Problems
These are the two most common SP-API errors in the Linnworks Amazon integration — and they are not variants of the same problem. They look alike in channel logs (both surface as SP-API errors, both can halt order downloads) but have different causes and different fixes.
Cause: Exceeded Amazon's SP-API request rate for that operation. Amazon enforces burst + sustained limits. Rate token refills over time — if Linnworks calls faster than the refill, throttling repeats.
Common trigger: Bulk listing feed + Inventory API calls running simultaneously. Both compete for the same rate limit bucket during high-volume sync. 429 responses in channel log.
Fix: Rate management. Linnworks' exponential backoff handles transient throttling automatically. Persistent = sync frequency too aggressive. Reduce polling or stagger bulk feed and inventory operations.
Cause: Linnworks is attempting an SP-API operation it doesn't have scope permission for. Scope wasn't granted at authorisation, was removed after the initial connection, or the SP-API token expired and wasn't refreshed.
Common trigger: Amazon periodically reviews SP-API app permissions in Seller Central. If Linnworks' scopes were revoked or downgraded — after an Amazon policy change or account security review — all calls for that scope return AccessDenied.
Fix: Authentication, not rate. Check Seller Central → Apps & Services → confirm Linnworks has all four role scopes. If missing: Linnworks → Channel Integration → Amazon → Re-authorise. Do not create a new channel.
| Scope | Operation | Failure symptom |
|---|---|---|
| Selling Partner Insights | Order download | Orders stop appearing in Linnworks; AccessDenied on GetOrders |
| Fulfilment Inventory | FBA stock read | FBA inventory levels no longer update in Linnworks |
| Orders | FBM despatch confirmation | Tracking fails to push; FBM orders stay "Unshipped" in Seller Central |
| Feeds | Bulk listing updates | Bulk feed calls fail silently; product data not updated |
If you're seeing inconsistent failures — some operations working, others not — identify which scope is producing the error and check that specific scope in Seller Central. Our Linnworks consultants can run this diagnostic quickly.
FBA vs FBM Stock Pool Collision: Why Linnworks Can Cause Amazon Oversells
This failure mode catches merchants running both FBA and FBM through the same Linnworks stock master — and it does real damage before anyone notices.
If you list the same SKU as both FBA and FBM, you have two separate stock pools: units at Amazon's warehouse (FBA) and units at your warehouse (FBM). Without the right Linnworks setting, Linnworks can push FBM stock levels to Amazon that don't account for FBA allocations — or decrement the same stock twice — creating phantom availability and oversell on FBM lines.
The fix: Enable "Use Channel Specific Stock Levels" in Linnworks → Settings → Channel Integration → Amazon → Channel Settings. This separates FBA and FBM stock pools so each fulfilment route draws from the correct source. Without it, FBA fulfilments can silently deplete the FBM stock counter in Linnworks — generating oversell risk on your warehouse-fulfilled lines even when physical stock is adequate.
Verify: With the setting active, a SKU you run as both FBA and FBM should show separate FBM and FBA stock figures in Linnworks — not a single aggregated number.
Bulk listing feed + Inventory API collision (separate issue): When Linnworks runs a bulk listing feed update simultaneously with an Inventory API stock push for the same SKUs, Amazon's feed processing queue can stall the inventory update — delaying stock level changes by 30–90 minutes. This is Amazon's feed queue latency, not a Linnworks fault. The fix: schedule bulk listing feed updates outside peak trading hours to avoid the concurrent collision window.
This is the same category of oversell risk as the polling window in the Linnworks Shopify integration — but Amazon's version compounds the lag because Amazon's feed processing queue adds additional latency on top of the base polling interval.
Amazon-Specific Linnworks Behaviour You Need to Know
FBA inventory updates in Linnworks reflect what Amazon reports via the Fulfilment Inventory API — not real-time warehouse movements. During peak periods, Amazon's FBA data can lag 4–6 hours behind actual stock levels. This is Amazon's latency, not a Linnworks issue. Plan FBA restock decisions accordingly — particularly for fast-moving lines during seasonal peaks.
When Linnworks hits Amazon's burst rate limit, exponential backoff kicks in — retry intervals extend to 30–60+ minutes during sustained high volume. On peak trading days, this can push order download and stock updates outside Amazon's seller performance windows. Check channel logs after every high-volume period.
When Linnworks pushes FBM despatch confirmation, Amazon sends the buyer notification. The buyer receives Amazon's standard "Your order has shipped" email. Linnworks triggers it; Amazon owns the communication. Tracking confirmation or buyer message customisation must be configured in Seller Central, not in Linnworks.
Amazon returns — FBA and FBM — do not automatically reinstate stock in Linnworks. Linnworks receives no FBM stock-back signal on return. Every return quietly understates available warehouse stock without a manual process. Same behaviour as the Linnworks eBay integration and Linnworks WooCommerce integration — different channel, identical blind spot.
Before You Go Live: 8-Point Amazon Pre-Launch Checklist
- SP-API scopes verified: All four role scopes granted in Seller Central — Selling Partner Insights, Fulfilment Inventory, Orders, Feeds
- SKU match verified: Linnworks item SKU = Amazon Seller SKU — case-sensitive, no trailing spaces, every active listing
- "Use Channel Specific Stock Levels" enabled: Linnworks → Channel Integration → Amazon → Channel Settings — active for any SKU listed as both FBA and FBM
- FBA vs FBM routing confirmed: Order download rules route FBA orders (no warehouse despatch) and FBM orders (your warehouse despatches) into separate Linnworks folders
- MWS legacy check: If connection predates 2024 — verify SP-API in Linnworks → Channel Integration → Amazon → connection details. If MWS: re-authorise via SP-API before going live
- Test FBM order placed: End-to-end test — download to Linnworks, despatch, tracking push to Amazon Seller Central. Confirm "Shipped" status in Seller Central — not just "Despatched" in Linnworks.
- Bulk feed scheduling reviewed: Confirm bulk listing feed updates are not running concurrently with inventory sync for large catalogues — stagger to avoid queue collision
- FBA restock lag documented: 4–6 hour FBA inventory data lag noted for operations team — prevents incorrect restock decisions during peaks
When to Use a Linnworks Amazon Specialist
- FBM-only, single warehouse
- Standard catalogue size (<500 SKUs)
- Single Amazon marketplace (UK)
- SP-API authorised correctly from the start
- No FBA/FBM hybrid on the same SKUs
- FBA + FBM hybrid fulfilment on the same SKUs
- Legacy MWS connection needing SP-API migration
- Amazon + eBay + storefront via one Linnworks stock master
- High-volume catalogue with bulk feed + inventory collision risk
- Existing oversell problem not resolved by checklist
- AccessDenied errors not resolved by re-authorisation
Running Amazon alongside eBay or your own storefront through the same Linnworks account is a multi-channel stock master architecture question, not just an Amazon integration question. Every FBA allocation, FBM despatch, and bulk listing update runs against the same stock master — and the rate limit windows and feed processing queues on Amazon's SP-API mean timing and sequencing matter more here than on any other channel in the Linnworks ecosystem.
If you've worked through the checklist above and are still seeing stock pool issues, persistent ThrottlingException or AccessDenied errors, or a legacy MWS connection that isn't behaving correctly after re-authorisation, that's the point where a specialist diagnosis saves more time than further self-diagnosis.
Whether you're setting up SP-API for the first time, migrating from a legacy MWS connection, or diagnosing a stock pool collision generating oversells, we've dealt with this before.
Talk to a Linnworks specialist →