Crosslist from WooCommerce to Amazon — the WordPress store as your master catalogue

On this page

• Why a WordPress store is the easiest starting point
• The GTIN field, and the gap you need to know about
• Variable products, and how Amazon sees them
• Checking your categories before you build anything
• How it works, from the WordPress admin
• What travels from a WooCommerce product to an Amazon offer
• Stock, price and the single source of truth
• What syncs, and the direction that does not
• Does it slow the site down?
• What it costs
• Sources and verification
• Related guides

Why a WordPress store is the easiest starting point

If you run a WooCommerce store — the WordPress e-commerce plugin that powers a very large share of independent online shops — you already have the thing that makes Amazon difficult for everyone else. You have a real product database.

Consider the alternatives. A seller crosslisting from a marketplace has titles and photographs and very little else, because marketplaces do not ask for structured product data. A seller crosslisting from a classifieds site has free text. Both have to build a catalogue before Amazon will look at them. You do not: WooCommerce has been making you fill in SKUs, attributes, stock levels, weights and dimensions since you set the store up, and those are precisely the fields an Amazon submission wants.

There is a second, less obvious advantage. Because WordPress is yours, your catalogue is not hostage to a marketplace’s export policy. If you decide next year that Amazon is not working, the products stay where they are. That is not true in the other direction, and it is a good reason to treat the WooCommerce store as your master catalogue and every marketplace, Amazon included, as an output of it.

The mental model to hold: WordPress holds the truth, FLUF distributes it, Amazon is one of the places it lands.

The GTIN field, and the gap you need to know about

Amazon is a catalogue rather than a listings board. Your offer attaches to a product page that already exists, identified by a ten-character ASIN, so Amazon has to be told which entry you mean — via an ASIN directly, or via a barcode that resolves to one: an EAN, UPC, GTIN or ISBN.

WooCommerce has had a native field for exactly this since version 9.2, on the Inventory tab of every product, labelled for GTIN, UPC, EAN or ISBN. Under the hood WooCommerce stores it as _global_unique_id. If you sell manufactured goods and you have been diligent, it is probably already populated across your catalogue.

Here is the honest caveat, and it is a limitation on our side rather than WooCommerce’s. FLUF’s Amazon resolver looks for a barcode in product meta named gtin, _gtin, _ean, ean, barcode, _upc, upc, isbn or _isbn, and failing those, in a product attribute called barcode or ean. It does not currently read WooCommerce core’s own _global_unique_id. So a store that filled in Woo’s built-in box, and only that box, will see Amazon refuse its products for a missing identifier even though the data is sitting right there.

Until that is fixed, the workaround is a one-off: copy the value into a gtin meta field or a barcode product attribute. If you are handy with WP-CLI that is a single query across the catalogue; if you use a bulk product editor plugin it is a column copy. We would rather tell you this than let you discover it one refusal at a time.

Whichever field it lands in, the format rules are Amazon’s. FLUF strips punctuation and accepts only genuine GTIN lengths — 8 for EAN-8, 10 for ISBN-10, 12 for UPC-A, 13 for EAN-13 or ISBN-13, and 14 for GTIN-14. A twelve-character internal reference is not a barcode, and it will be rejected rather than guessed at.

If your products genuinely have no barcode — your own brand, or something you make — Amazon’s product ID exemption is the route, and the Amazon guide covers how to get one.

Variable products, and how Amazon sees them

This is where a WooCommerce catalogue and an Amazon catalogue disagree most sharply, and it is worth understanding before you push a hundred products.

In WooCommerce, a variable product is one product with variations hanging off it — a shirt in four sizes and three colours is a single item in your admin with twelve variations underneath. That structure is a convenience for you and a convenience for your shoppers.

Amazon has no way to receive that structure from a crosslisting tool. Each thing a buyer can actually buy is its own catalogue entry with its own identifier. A twelve-variation product is twelve barcodes, or it is nothing.

The practical consequences:

• If your manufacturer issued a barcode per variant — which is normal for clothing, footwear and packaged goods — you already have what you need, and the work is making sure each variation carries its own value rather than inheriting the parent’s.
• If you assigned one barcode to the parent product and left the variations blank, every variation resolves to the same Amazon entry, which is wrong and will eventually send someone a medium instead of a large.
• If your variations are things a manufacturer never barcoded — a length you cut to order, a personalisation option — there is no clean Amazon mapping, and the honest answer is to keep that product on your WordPress store and on channels that model variants properly.

A useful discipline: treat the barcode field as the test of whether a variation is a real, distinct, stockable product. If you cannot name one, it probably is not.

Checking your categories before you build anything

All of the above is wasted effort if Amazon will not take your category, so do this check first. It takes five minutes and it has saved sellers weeks.

Amazon’s published UK condition guidelines carry an explicit New-only section covering Apparel, Shoes and Bags, Sports, Baby, Pet and Grocery, plus everything consumable, ingestible or topical — Beauty, Food, Health Care and Vitamins. Its wording on the first is flat: “Only New items are permitted to be sold in the Apparel category on Amazon.co.uk.”

For most WooCommerce stores this is fine, because most WooCommerce stores sell new goods. Where it bites is the growing number of WordPress shops built around second-hand or reclaimed stock — vintage clothing, pre-loved designer, refurbished gear. If that is you, Amazon is closed for the clothing side of the catalogue whatever your data quality, and the effort is better spent on channels that want it.

Beyond condition, Amazon gates various categories behind pre-approval. The symptom is silent: when a product is in a gated or New-only category the used and refurbished options simply do not appear, with no error explaining why.

How it works, from the WordPress admin

The whole setup happens in two places — your WordPress dashboard and Amazon’s own consent screen.

1. Install the FLUF Connect plugin for WooCommerce from your WordPress admin. Plugins → Add New, search for FLUF Connect, install and activate, exactly as you would any other WordPress plugin.
2. Connect your WooCommerce store. The plugin authenticates your store against your FLUF account and imports your products, with their SKUs, attributes, stock levels and images intact.
3. Get a Professional Amazon seller account. Third-party API integration is a Professional-plan capability; an Individual account cannot authorise FLUF at all.
4. Connect Amazon in FLUF Connect. You are sent to Amazon’s own consent screen on Amazon’s domain, where you approve the connection. No password is ever shared with us, and there is no browser extension involved on either side of this route.
5. Check the resolved region and currency. Amazon regionalises everything, and your seller account’s marketplace determines the currency prices are submitted in.
6. Fix your identifiers — see the GTIN section above — then push one product and read what comes back before scaling.

Amazon requirements vary by product category. Review the required attributes before your first batch, try a small number of listings first, and contact support if you cannot resolve a publishing issue.

What travels from a WooCommerce product to an Amazon offer

Two mechanical notes. Your WordPress-hosted images are sent to Amazon as URLs and fetched by Amazon rather than uploaded, so they must be publicly reachable — a store behind a maintenance-mode plugin or HTTP authentication will produce listings with no photographs and no error message, which is worse than a rejection. And descriptions are stripped of HTML, because Amazon’s description attribute officially takes plain text; if your product copy leans on formatting, the Amazon version will read flatter than the version on your own site.

Updates are sent as patches rather than replacements. Anything you set by hand in Seller Central survives a price change pushed from WordPress, instead of being silently wiped.

Stock, price and the single source of truth

The reason to run this route through your WordPress store rather than managing Amazon separately is that stock stops being a thing you reconcile.

WooCommerce already decrements stock when someone buys on your own site. With FLUF connected, that decrement propagates: the Amazon quantity follows, and so does every other channel you have connected. Price changes work the same way — edit the product in WordPress, and the new price goes out.

Two habits are worth adopting deliberately. First, make the edits in WordPress rather than in Seller Central, so there is one place the truth lives; edits made directly on Amazon survive, but they create a divergence you will forget about. Second, be careful with any WooCommerce plugin that mass-edits prices or stock — a bulk change you did not think of as a crosslisting action will propagate to Amazon just as faithfully as one you did.

What syncs, and the direction that does not

Works today. A sale on your WooCommerce store, or on any other connected channel, sets your Amazon quantity to zero. Price and stock updates push to Amazon. Listings can be removed.

Does not work yet. A sale on Amazon does not write back. Order sync is not claimed on the Amazon channel, so an Amazon order will not appear in your WooCommerce orders and will not decrement WooCommerce stock. You will see it in Seller Central and nowhere else.

For a store owner that asymmetry is more consequential than it is for a marketplace seller, because your WooCommerce stock number is the one you trust. Until Amazon order sync ships, the discipline is: check Seller Central for Amazon orders, and adjust WooCommerce stock when one arrives.

The delay is deliberate rather than an oversight, and the Amazon guide explains the order-status problem behind it. The short version: a premature sold-signal would zero real stock across your whole store for a sale that never completed.

Also worth knowing for planning: Amazon supports none of FLUF’s automation features. Repricing against the other offers on a shared Amazon page is manual.

Does it slow the site down?

A fair question about any WordPress plugin, and one worth answering directly rather than reassuringly.

The FLUF Connect plugin for WooCommerce does not put marketplace calls on your customers’ page loads. The work that matters — publishing to Amazon, pushing price and stock updates, reconciling channels — happens on FLUF’s infrastructure, not inside your WordPress request cycle. What the plugin does on your side is authenticate the store and let changes to products be picked up.

The honest caveat is the one that applies to every WordPress site: if your store is already heavy with plugins, on shared hosting, and without object caching, adding anything at all is felt. If you are running a large catalogue, the usual WooCommerce advice applies regardless of us — a persistent object cache, a database that has had its transients cleared this decade, and a hosting plan sized for the number of products you actually have.

What it costs

7 days for £1, then from £9/month. There is no free plan and no free tier.

Crosslisting, inventory sync, order sync and bulk operations are on every plan. Relisting, offer management and smart pricing are included from Seller (£29/month) upwards; Starter does not include them. Paying annually saves 40%.

Amazon’s own costs sit on top and are separate: a Professional plan at £25 excluding VAT a month in the UK or $39.99 in the US, plus a referral fee on each sale, which Amazon’s pricing pages put between 5% and 45% depending on category.

Sources and verification

Every rule, field and limit was checked against a primary source on 7 September 2026.

• WooCommerce’s product data store documentation and the WooCommerce plugin source — the global_unique_id product property and its _global_unique_id meta key, added for GTIN, UPC, EAN and ISBN values, and its presence in the product lookup table.
• Amazon’s GTIN guide and Amazon on generic products — that a GTIN is “a globally unique number up to 14 digits long” recognised as UPC, ISBN, EAN or JAN; the exemption grounds; the “I don’t have a product ID” application flow; the roughly 48-hour approval; and the per-category, per-store scope.
• WooCommerce’s product management documentation — the Inventory tab, SKU handling, stock management and the variable-product model described above.
• Amazon’s UK Condition Guidelines (PDF) — the New-only category restrictions quoted above.
• Amazon’s UK selling plan pricing and its US equivalent — the plan fees and referral ranges quoted.
• Amazon’s Listings Items API reference — the two submission paths and the patch-rather-than-replace update behaviour.

What we could not verify, and therefore left out. The WooCommerce release that introduced the GTIN field: we confirmed the property and its _global_unique_id meta key directly in the WooCommerce source we run against, but not the release note, so treat “since 9.2” as our best understanding rather than a cited fact. Whether any third-party WooCommerce GTIN or barcode plugin happens to store its value under a key FLUF already reads — there are several such plugins, we have not surveyed them, and you should check your own field name rather than assume. Whether WooCommerce variation-level GTINs are populated by default in any given store’s import or feed tooling, which varies far too much between setups for us to generalise. And the performance impact of the plugin on a specific site, which depends on hosting, plugin count and caching to a degree that makes any published number misleading — measure your own site rather than trusting ours.

Related guides

• Sell on WooCommerce — the WordPress seller guide
• Sell on Amazon — the complete seller guide
• Crosslist from eBay to Amazon
• Crosslist from WooCommerce to eBay
• Crosslist from WooCommerce to Etsy
• Amazon vs eBay — a catalogue against a listings board
• All marketplace guides
• All crosslisting routes
• Crosslist from Shopify to Amazon
• Crosslist from PrestaShop to Amazon