Linnworks WooCommerce Integration: How to Set It Up, What Breaks, and How to Fix It

The Linnworks WooCommerce integration is not a plug-and-play App Store install. Unlike Shopify — where Linnworks connects via a single OAuth flow — WooCommerce uses a REST API connection you configure manually. That extra configuration step is also where most problems start. Get it right once and it runs reliably. Get it wrong — or run it on the wrong hosting environment — and you'll be chasing stock discrepancies and missing orders for months without knowing why.

This guide covers the full integration: what syncs and what doesn't, the step-by-step setup process, the REST API throttling problem specific to WooCommerce on shared hosting, the three most common sync failures with root causes, and what changes if you're migrating from Magento. For hands-on help, our Linnworks integration specialists work across all three platforms.

What the Linnworks–WooCommerce Integration Actually Does

Linnworks connects to WooCommerce via the WooCommerce REST API v3. Here's what the integration handles — and where it stops:

Data type	Direction	Notes
Orders	WooCommerce → Linnworks	Downloads when order status matches your configured download rules. Default: `processing`. WooCommerce has a larger custom status ecosystem than Shopify — plugins can add statuses Linnworks doesn't recognise by default.
Stock levels	Linnworks → WooCommerce	Linnworks is the stock master. Updates push via REST API — one PUT request per SKU. On shared hosting, throttling can delay updates 30–120 minutes.
Shipping confirmation / tracking	Linnworks → WooCommerce	Marks WooCommerce order as completed and pushes tracking number when despatched in Linnworks.
WooCommerce custom meta fields	Does NOT sync	Custom product meta (ACF fields, WooCommerce custom attributes beyond standard product data) not accessible to Linnworks natively.
WooCommerce Subscriptions orders	Does NOT sync by default	WC Subscriptions creates its own order types. Renewal orders may use a status not in your Linnworks download rules — map these manually before go-live.
WooCommerce refunds / restocks	Does NOT auto-sync	A WooCommerce refund does NOT automatically reinstate stock in Linnworks. Manual adjustment or a return flow rule required.

Setup Process: Step by Step

Unlike the Shopify App Store OAuth flow, the WooCommerce connection requires manual API key generation and channel configuration. Allow 30–60 minutes for a clean first setup.

Step 1

Pre-setup requirements

Linnworks Standard plan or above. WooCommerce on a self-hosted WordPress site (plugin version 3.5+). Admin access on both platforms. Confirm your warehouses, default currency, and sync direction before starting.

Step 2

Generate WooCommerce REST API key

WordPress Admin → WooCommerce → Settings → Advanced → REST API → Add Key. Set Description (e.g. "Linnworks"), User (admin), and Permissions: Read/Write. This is critical — WooCommerce defaults to Read-Only if you miss the permissions dropdown. A Read-Only key will connect successfully but stock write-back fails silently. Copy Consumer Key and Consumer Secret immediately — shown once only. This is architecturally different from the Linnworks Magento integration, which uses OAuth token exchange rather than static API keys.

Step 3

Add WooCommerce channel in Linnworks

Linnworks → Settings → Channel Integration → Add New → WooCommerce. Enter your store URL, Consumer Key, and Consumer Secret. The channel is added from within Linnworks — it is NOT installed via the WooCommerce plugin directory. Merchants who search the WooCommerce Marketplace for a "Linnworks plugin" are looking in the wrong place.

Step 4

Channel mapping

Assign your warehouse to the WooCommerce channel, set default currency, confirm stock push direction (Linnworks → WooCommerce). If multiple warehouses, assign the correct one — stock only pushes from the mapped warehouse.

Step 5

SKU reconciliation — the most common setup failure

The Linnworks item SKU must exactly match the WooCommerce product SKU field — character for character, case-sensitive. For variable products, every variation needs its own SKU in the WooCommerce variation SKU field. WooCommerce does NOT enforce SKU uniqueness — legacy stores frequently have blank SKU fields on variable product attributes. Go to Products → each product → check the SKU (and each variation's SKU). Blank = unmapped = stock will not sync for that item. This is more prevalent on WooCommerce than Shopify because WooCommerce doesn't flag missing SKUs at the product level.

Step 6

Order download rules

Set which WooCommerce order statuses trigger download to Linnworks. Default: processing. Standard statuses: pending, processing, on-hold, completed, cancelled, refunded, failed. Plugins add more. Map all relevant statuses before go-live — a missing status means those orders simply don't appear in Linnworks.

Linnworks WooCommerce Not Syncing? Your Host Is Probably the Cause.

This is the failure mode that doesn't exist in the same way on Shopify or Magento. It accounts for a significant proportion of Linnworks WooCommerce support cases — and it's rarely labelled correctly when it surfaces.

Why shared hosting breaks Linnworks sync

WooCommerce runs on WordPress, which runs on shared hosting for the majority of UK SMBs. Linnworks connects via the WooCommerce REST API v3 — and the critical detail is this: there is no batch endpoint. Linnworks pushes stock updates as individual PUT requests, one per SKU. For a catalogue of 500 SKUs, that's 500+ separate HTTP requests per sync cycle.

On shared hosting — SiteGround, Hostinger, Bluehost — PHP execution time is capped, memory is constrained, and concurrent request handling is limited. Under a Linnworks sync load, those limits trigger:

What you see in WooCommerce

Stock figures that update hours after a despatch — or don't update at all. No error, no alert. Just a slowly growing divergence between what Linnworks says and what WooCommerce shows.

What you see in Linnworks channel logs

429 Too Many Requests or 500 Internal Server Error in the WooCommerce channel log. Or the more opaque failure: Task cancelled — timeout exceeded — the hosting environment killed the PHP process mid-sync before Linnworks could confirm the write. No retry, no alert. The update simply didn't happen.

What you see in WP debug.log

On SiteGround and Hostinger, a ModSecurity WAF rule can intercept Linnworks' REST API calls — ModSecurity: Access denied in the server error log, paired with a 403 response code. Linnworks reports a successful sync while WooCommerce receives nothing. This requires checking server-side WAF logs to diagnose.

The stock divergence window on WooCommerce is significantly longer than on Shopify. The Linnworks Shopify integration uses Shopify's native webhook infrastructure for near-real-time stock push — a fundamentally different architecture that bypasses API rate limits entirely. WooCommerce merchants on shared hosting don't have that option.

Fix hierarchy (work through these in order)

Check the channel log first

Linnworks → Channel Integration → WooCommerce → Channel Log. Filter for errors. 429 or 500 = hosting constraint. Task cancelled — timeout exceeded = PHP execution limit killing the sync process. Free diagnosis — identifies the problem in under two minutes.

Check WP debug.log for WAF blocks

Enable WP_DEBUG_LOG in wp-config.php and check /wp-content/debug.log for ModSecurity entries. SiteGround and Hostinger run mod_security by default. A WAF block on Linnworks' IP range is a server configuration issue — contact your host and ask them to whitelist Linnworks' IP range or adjust the blocking WAF rule.

Reduce sync frequency

In Linnworks WooCommerce channel settings, increase the sync interval from 15 to 30–60 minutes. Fewer calls per cycle reduces throttling risk. Trade-off: longer stock update lag — document this so your team understands the intentional delay.

Request a PHP limit increase from your host

Some managed shared plans (SiteGround GoGeek, Hostinger Business) allow PHP execution limit increases on request. Helps at the margins but doesn't eliminate the shared-resource constraint.

Move to a VPS or managed WordPress host

For stores with 500+ SKUs or significant daily order volumes, this is the right long-term answer. VPS (Cloudways, DigitalOcean) and managed WordPress hosts (Kinsta, WP Engine) don't impose PHP execution constraints. Linnworks sync runs cleanly, reliably, at full polling frequency. The cost difference is typically £30–£100/month. For any merchant where a 30-minute stock lag creates real oversell risk, that cost pays back fast. Our Linnworks consultants can advise on the right hosting configuration for your catalogue size.

The 3 Most Common Sync Failures (With Causes and Fixes)

REST API throttling explains a large share of WooCommerce sync failures — but not all. These three are the next most common, and none generate a clear alert in either platform.

Failure 1: Stock Not Updating in WooCommerce After Linnworks Despatch

Root cause

Beyond hosting throttling, the other cause is polling interval lag. Unlike the Shopify integration — which offers webhook-based real-time stock push on Linnworks Standard+ — there is no real-time push option for WooCommerce. Every stock update goes via REST API on your configured interval, regardless of urgency. A despatch in Linnworks waits for the next sync cycle before it reaches WooCommerce.

Fix: Reduce the sync interval in Linnworks → Channel Integration → WooCommerce → channel settings. Balance this against API call density — tighter intervals mean more frequent calls and higher throttling risk on shared hosting. If you're hitting both problems simultaneously, the hosting upgrade (Step 5 above) is the right answer, not a toggle war between interval settings.

Failure 2: Orders Not Downloading from WooCommerce to Linnworks

Three distinct root causes — diagnose in this order:

(a) Payment status not in download rules

WooCommerce's status set is larger than Shopify's, and plugins expand it further. Klarna and Clearpay payments land in on-hold before moving to processing — if on-hold isn't in your download rules, those orders sit in WooCommerce unprocessed while pick-and-pack waits. BACS orders start as pending. Check Settings → Channel Integration → WooCommerce → Order Download Rules in Linnworks and add every status your payment gateways and plugins generate.

(b) SKU mismatch on variable product attributes

WooCommerce does not enforce SKU uniqueness. Many legacy stores have variable products where the parent has a SKU but the individual size/colour variations don't. Orders for these variants download to Linnworks but line items can't be matched to inventory items. Fix: Linnworks → Settings → Channel Integration → WooCommerce → Listings → filter by "No SKU Match". Correct every blank variation SKU in WooCommerce to match the corresponding Linnworks item SKU exactly.

If the WooCommerce REST API key used by Linnworks is regenerated — by a WordPress security plugin, a developer, or a WooCommerce update — Linnworks loses its connection silently. It will also fail silently if the key's permissions were changed to Read-Only. Fix: WordPress Admin → WooCommerce → Settings → Advanced → REST API → check the Linnworks key still exists and shows Read/Write permissions. If not, generate a new key and update the credentials in Linnworks channel settings.

Failure 3: SKU Mismatch on Variable Products — Why WooCommerce Is Different

Root cause

WooCommerce allows variable products to have no SKU on individual variations. Shopify requires a unique variant SKU. Magento enforces a unique SKU per product. WooCommerce doesn't. A merchant can create 50 size/colour variations and never set a single variation SKU — Linnworks can't map these to inventory items. The integration exists, but nothing syncs for those SKUs.

Fix: Before go-live, run a SKU audit in WooCommerce. Products → All Products → filter by Variable. For every variable product, check every variation has a populated SKU field that matches the Linnworks item SKU. Use WP All Export or a similar tool for bulk export/reimport of SKUs at scale.

WooCommerce REST API Endpoint Reference

These are the specific endpoints Linnworks uses when communicating with WooCommerce — useful for diagnosing WAF blocks or permission issues in server logs:

Operation	Endpoint	Method
Download orders	`/wp-json/wc/v3/orders`	GET
Update order status	`/wp-json/wc/v3/orders/{id}`	PUT
Update product stock	`/wp-json/wc/v3/products/{id}`	PUT
Update variation stock	`/wp-json/wc/v3/products/{id}/variations/{id}`	PUT
List products	`/wp-json/wc/v3/products`	GET

Migrating from Magento to WooCommerce: What Changes in Linnworks

If you're running a Magento 2 to WooCommerce migration, your Linnworks account carries over — but the channel connector type changes completely.

Magento connector (before migration)

Server-side Linnworks extension installed on Magento. Cron-based sync. Order download via Magento API events. Stock sync runs server-side — not PHP execution limited in the same way.

WooCommerce connector (after migration)

REST API-based. Configured manually (Consumer Key + Secret). Polling-based sync. Subject to shared hosting PHP limits. Different sync architecture — more sensitive to hosting environment quality.

The critical migration rule: preserve your Linnworks item SKUs in WooCommerce's product SKU fields. Do not let WooCommerce auto-generate new SKUs during import. If the SKUs don't match, the entire stock sync fails for those products. Rebuild your WooCommerce product catalogue with the Linnworks SKU as the WooCommerce product/variation SKU from day one.

After migration: disconnect the Magento channel in Linnworks (Settings → Channel Integration → Magento → Remove). Set up WooCommerce as a new channel using the steps above. Test with a small order volume before going live on the new stack.

Is Linnworks the Right Choice for WooCommerce?

Linnworks is the right choice for multi-channel WooCommerce merchants — those selling on eBay, Amazon, and other channels alongside their WooCommerce store, and needing a single system to manage stock and orders across all of them. For single-channel WooCommerce stores, native WooCommerce inventory management may be sufficient.

Where Linnworks earns its cost on WooCommerce: when you're dispatching 50+ orders per day across multiple channels and the alternative is manually updating stock across each platform. The integration pays for itself by eliminating oversells and manual reconciliation. The hosting environment question is real — but manageable. If your WooCommerce store is on shared hosting and you're planning to use Linnworks seriously, factor a VPS or managed WordPress host into your integration plan from the start.

Questions about whether Linnworks fits your specific WooCommerce setup? Our Linnworks integration team has set this up across dozens of UK merchants.