WooCommerce Amazon integration: what I check before trusting a plugin

What WooCommerce Amazon integration actually means

Four different jobs hide behind the same search phrase, and they need different tools. Before you compare plugins, decide which row below you are actually in — most failed setups I am asked to rescue picked a tool built for a different row.

Rows one to three are marketplace integration. Row four is affiliate publishing. If you are in row four, stop reading comparison posts about sync plugins — nothing below applies to you.

How a WooCommerce to Amazon sync actually works under the hood

Every credible tool in this space talks to the same thing: Amazon's Selling Partner API. The plugin is a queue, a field mapper and a retry loop wrapped around it. Knowing what the API can and cannot do tells you more about a plugin's real behaviour than its feature list does.

The constraint that shapes everything is throttling. Amazon meters SP-API with a token bucket: tokens refill at a fixed rate up to a burst ceiling, each call spends one, and an empty bucket returns HTTP 429. Buckets are tracked per application and seller pair and per operation, and some operations use dynamic plans whose limits move with the seller's business metrics rather than with how hard the app calls. Amazon's own guidance is to back off exponentially and watch the rate limit response header. See Amazon's SP-API usage plans and rate limits documentation.

Two practical consequences that plugin marketing never states plainly:

• Real-time sync means queued. A 500-SKU price change is 500 queued operations against a shared bucket. Run a flash sale in WooCommerce and your Amazon prices will lag behind it for a while.
• You share the bucket with yourself. Two tools authorized against the same seller account compete for the same tokens. I have watched an inventory sync starve because a reporting script in the same account was burning the bucket every minute.

If you sell fast-moving, low-stock items, do not try to win this with a shorter sync interval. Hold a buffer: expose less stock on Amazon than you physically have, sized to roughly the worst-case sync lag you measured during your first busy week.

Matching an existing ASIN or creating a new listing: where most Woo catalogs stall

Teams expect the hard part to be the API. It is almost never the API. It is that Amazon's catalog refuses the product data a typical WooCommerce store holds.

Two paths exist, and the tool only automates the easy half of each:

1. Match to an existing ASIN. You are reselling something already in the catalog. You supply the identifier and an offer: price, quantity, condition, fulfilment channel. Fast, when the match is clean.
2. Create a new listing. You are the brand. Now Amazon wants a product type, the required attributes for that product type in that marketplace, and a product identifier — usually a GTIN such as a UPC or EAN, unless you hold a brand registry based exemption.

Stock WooCommerce has no GTIN concept at the schema level, so for most stores the identifier lives in a custom field, a plugin's field, or nowhere at all. The sync then fails at submission, per SKU, with errors that only appear inside the feed processing report. Before touching a plugin, I run this check on the catalog export:

• What percentage of SKUs have a valid, brand-owned GTIN? Recycled or purchased barcodes get listings suppressed later, not rejected now.
• Do variable products map to one Amazon parent with a legal variation theme, such as size and colour, or are they unrelated items glued together for merchandising?
• Is the brand gated, and is the category one that needs approval before any listing goes live?

Answer those three before you pay for anything. A catalog that fails all three will fail with every tool on the market, which is why plugin reviews for this category are so polarised — the same software looks excellent to a branded seller with clean data and useless to a dropshipper without identifiers.

If you are searching for Codisto for WooCommerce, it is closed

Codisto was for years the default answer to this question, and a lot of still-ranking tutorials tell you to install it. Its WooCommerce plugin was closed on the WordPress.org plugin directory as of 1 December 2025, with the directory listing a security issue as the reason and the plugin no longer available for download, having last been updated years earlier. You can see the notice on the plugin's WordPress.org directory page.

The general lesson matters more than the specific plugin. A marketplace connector holds a live authorization to your Amazon selling account and sits inside your WordPress install. An unmaintained one is two risks at once: an unpatched attack surface on your site, and a credential path into the account that holds your revenue.

So treat maintenance as a hard filter, not a nice-to-have. If a connector has not shipped an update since before the last round of SP-API changes, it is not a cheaper option — it is an outage waiting for a schema change. And if you are currently running a closed or abandoned connector, revoke its authorization in Seller Central first, then uninstall. Deleting the plugin alone leaves the grant in place.

How to choose a WooCommerce Amazon integration plugin: eight checks

Feature grids all look the same because every tool wraps the same API. These are the questions that actually separate them, in the order I ask them.

One licensing note, since this is a WordPress ecosystem: a self-hosted GPL plugin and a hosted SaaS connector carry different risks. Self-hosted puts the credentials and the maintenance burden on you; SaaS puts your catalog in someone else's infrastructure and makes their uptime your uptime. Neither is wrong, but pick deliberately, and if the answer is that you would rather hand the whole surface to someone who does it daily, that is what our marketplace integration service exists for.

Is there a free WooCommerce Amazon integration?

There are free tiers, and there is almost no genuinely free production sync. The honest version:

• Free tiers typically cap order volume or SKU count. They are fine for validating that your catalog can list at all, which is the question worth answering first.
• Free plugins that do only order import are real and useful. Pulling Amazon orders into WooCommerce for reporting is a far smaller problem than pushing listings.
• Building it yourself is free of licence cost and expensive in everything else. SP-API registration, token refresh, feed polling, per-marketplace required attributes and error triage are weeks of work before the first listing goes live, plus ongoing maintenance each time Amazon changes a schema.

The cost that actually bites is not the licence. It is reconciliation time when stock drifts, and lost Buy Box or suppressed listings while someone works out why. Price the tool against that, not against the monthly fee.

Adding eBay: should one tool handle Amazon and eBay?

This is a frequent follow-up, and the honest answer is that the two marketplaces are not equally hard, so a tool that handles both well is usually optimised for the harder one.

Practical guidance: get Amazon working on its own first. eBay forgives a messy catalog; Amazon does not. If Amazon is live and stable, adding eBay in the same tool is mostly configuration. Doing both at once means debugging two different failure vocabularies against one catalog, and you will not know which marketplace is telling you the truth about your data.

WooCommerce, Amazon and QuickBooks: where the accounting breaks

Once orders flow from Amazon into WooCommerce, the obvious next step is to let an existing WooCommerce to QuickBooks connector pick them up. That is where the books go wrong, for two reasons.

• Double counting. If anything else already syncs Amazon to QuickBooks, imported Amazon orders arriving a second time through WooCommerce inflate revenue. Pick exactly one path per channel and document it.
• Amazon does not pay you per order. It pays settlements: gross sales minus referral fees, FBA fees, refunds, reserves and adjustments, on Amazon's cycle. An order-level sync records revenue that never lands as cash at that amount, so your bank reconciliation will not close.

The arrangement that reconciles cleanly is to treat the two systems as answering different questions. WooCommerce holds operations — the order, the customer, the fulfilment state. QuickBooks takes Amazon revenue from the settlement report as a summarised journal entry per settlement period, with fees and refunds broken out to their own accounts. Order-level detail stays where it is useful and out of the ledger.

Do that and the Amazon deposit in your bank feed matches a single entry. Skip it and you will spend every month explaining a variance that was never a real discrepancy.

The checklist to run before you turn sync on

In order, because each step makes the next one cheaper:

1. Decide the direction of the integration from the first table, and write it down.
2. Export the catalog and measure GTIN coverage, variation structure and gated brands or categories.
3. Confirm the Amazon account is a Professional selling plan and the target marketplaces are open.
4. Pick one authority per SKU for inventory, and encode it before the first sync, not after the first oversell.
5. Start with ten SKUs, not the whole catalog. Watch a full cycle: list, sell, decrement, refund.
6. Read an actual feed processing report. If your tool cannot show you one, you have learned something important about your tool.
7. Set a stock buffer sized to the sync lag you observed, not the lag the vendor advertises.
8. Decide the accounting path before volume arrives, so settlements never get recorded twice.
9. Only then enable the full catalog, and keep the ten-SKU test group as your canary.

Most of the pain in this integration is data and authority, not software. If you would rather have the catalog audit, the identifier cleanup and the sync setup handled end to end, tell us what you sell and get a quote — it costs nothing to ask, and the answer will tell you whether your catalog is ready before you buy a licence.