Most serious Shopify brands I work with don't sell only on Shopify. They also sell on Amazon, or Walmart, or both — because that's where a large chunk of buyers already are. So they connect a feed, the listings go live, and for a while everything looks fine.
Then someone adds a colourway. Or renames a size. Or splits one product into two. Or fixes a typo in a title. A perfectly ordinary Tuesday in a growing catalog. And somewhere downstream, a marketplace quietly rejects a batch of listings — and the merchant doesn't find out from a dashboard. They find out from the sales report, weeks later, when a product that used to sell on Walmart simply stopped.
I helped a brand expand from Shopify onto a marketplace — Walmart's Canadian storefront — and the brief was, in effect, "we want our catalog live there, and we don't want to babysit it." That second half is the whole job. Getting a feed to go live once is the easy part. Keeping it live through a catalog that changes every week is where the real work lives, and it's work almost nobody wants to own.
"Connected" is not the same as "selling"
Same trap as products that don't show in Google: a green light on an integration is a claim about a connection, not a fact about your listings. A feed can be "syncing" while a meaningful slice of your catalog sits in a rejected or suppressed state on the marketplace side — visible to no one until someone goes looking, item by item.
The feed isn't a pipe you connect once. It's a translator that has to keep two systems agreeing about every product, every variant, and every attribute — and the two systems were never designed to agree.
That's the core of it. Shopify models your catalog one way. Each marketplace models it a different way, with its own required fields, its own taxonomy, and its own opinions about what counts as a valid product. The feed lives in the gap between those models. Every catalog change is a fresh chance for the translation to fail.
Where the feed actually breaks
1. Variant grouping doesn't survive the trip. In Shopify, a product with five sizes and three colours is one product with fifteen variants. Marketplaces often want that expressed as a parent listing with child items grouped underneath — and the rules for what makes a valid group, and which attribute is the "variation theme," are specific and unforgiving. In my experience this is the single most common place a feed quietly mangles a catalog: the variants either collapse into one undifferentiated listing or scatter into orphaned singles, and either way the shopping experience on the marketplace breaks. Getting the grouping right isn't a setting you toggle once; it's logic the feed has to apply correctly to every product, including the ones you add next month.
2. Every item needs an identity the marketplace recognises. Marketplaces generally want a real product identifier — a GTIN, UPC, or EAN — and they want it to be valid, not just present. In the catalogs I audit, this is rarely clean: missing codes, codes typed into the wrong field, recycled codes shared across variants, or check-digit errors that look fine to a human and fail validation on submission. Remediating it is unglamorous, slow, and exactly the kind of work that gets deferred until a wave of disapprovals forces the issue. It has to be fixed at the source — in the Shopify data — or the feed just keeps re-submitting the same broken identity.
3. Your categories don't map to theirs. Each marketplace has its own product taxonomy, and your Shopify product types and collections almost never line up with it cleanly. A product placed in the wrong marketplace category can be miscategorised, suppressed, or held for review — and the mapping is a judgment call, not a lookup. In my experience this is where "just connect a feed" apps tend to guess, and guess badly, because the right category often depends on context the app can't see.
4. The disapprovals arrive in waves, and they're not all the same kind. When a batch gets rejected, the instinct is to treat it as one problem. It almost never is. Some rejections are data you can fix (a missing field, a bad identifier). Some are mapping decisions only the merchant can make (which category, which market). And some are policy walls the marketplace simply won't move on for that product type. Triaging the waves into those three buckets before touching anything is the difference between a half-day fix and a month of whack-a-mole — clear one batch blind and you'll often surface the next.
5. There's always a quirk the documentation doesn't warn you about. On one marketplace build I ran into a status the integration reported as an ordinary error, when in fact it was the marketplace signalling a temporary maintenance state on its own side — an inline string the feed was parsing literally and reacting to as if a listing had failed. In my experience every marketplace integration has at least one of these: a string, a status code, an edge case in how a value gets parsed, where the honest fix is recognising the quirk for what it is rather than "fixing" a listing that was never actually broken. You don't find these in the docs. You find them by watching the feed misbehave and refusing to accept the surface explanation.
The conflict nobody warns you about: who owns the listing
Here's the structural problem underneath all five. On a marketplace, your Shopify store is usually not the only source of truth for a product. The marketplace has its own catalog, and sometimes another seller's data — or the marketplace's own enrichment — is already attached to the same item. So you can push a perfectly correct feed and still see your title, image, or attributes overridden by content you don't control.
In my experience this content-ownership conflict is the part merchants find most maddening, because it doesn't behave like a bug — there's nothing in your store to fix. It's a question of which system the marketplace treats as authoritative for a given field, and resolving it is negotiation with the platform's rules, not a code change. Knowing the difference — what's yours to fix in the feed versus what's a contest over ownership you have to handle on the marketplace's terms — saves a lot of wasted effort aimed at the wrong layer.
Why this work falls through the cracks
The Shopify-to-marketplace feed sits between job descriptions, the same way the Google channel does. Your developer sees it as marketplace operations, not store code. Your marketplace manager sees broken listings and assumes it's a data or dev problem. The integration app's support points at the marketplace; the marketplace's support points back at your feed. Everyone is locally correct. The seam stays broken, and the cost shows up as marketplace sales that quietly never happen.
And because the catalog never stops changing, this isn't a one-time fix. It's an ongoing maintenance surface. A feed that's healthy today drifts out of sync the moment the catalog moves — which, for a growing brand, is constantly. That's not a flaw in your setup; it's the nature of keeping two systems agreed about a moving target.
What to do about it
1. Check the marketplace side, item by item, not the integration's status. The honest measure of feed health isn't "connected." It's what share of your catalog is actually live and buyable on the marketplace right now — and what share is rejected, suppressed, or silently overridden. That number is almost always worse than the dashboard implies.
2. Fix identity and grouping at the source, in Shopify. Bad GTINs and broken variant logic patched at the feed layer just get re-broken on the next sync. Clean product data in the store is the only fix that holds, because the feed re-reads from there every time.
3. Triage disapprovals into three buckets before you touch anything. Data you can fix. Decisions only you can make. Policy walls nobody can move. Most stuck marketplace expansions are stuck because all three are being worked as one undifferentiated pile.
4. Treat the feed as a thing that needs an owner, not a thing you finish. The reason this class of problem recurs isn't difficulty — diagnosed properly, most of it is a structured pass, not a rebuild. It recurs because the catalog keeps moving and nobody is watching the seam. On the Walmart build I mentioned, the durable fix wasn't a one-off cleanup — it was automating the variant-group feed so the grouping logic applied itself correctly to new products as the catalog grew, instead of breaking on each addition. Channel and feed health has to be someone's actual responsibility, the same way the theme and the ad spend are.
The bottom line
Selling on Amazon and Walmart alongside Shopify isn't a "set up a feed" project. It's a standing commitment to keep two systems agreeing about a catalog that won't hold still — through variant grouping, product identifiers, taxonomy mapping, disapproval triage, and the occasional undocumented quirk. The brands that win on marketplaces aren't the ones with the fanciest integration. They're the ones where someone actually owns the seam, so a routine catalog change on Tuesday doesn't turn into lost marketplace sales by Friday.
If you sell on a marketplace and you're not sure how much of your catalog is genuinely live there right now, that's exactly the kind of thing I can pin down fast. Grab a slot and bring your store URL and the marketplaces you sell on — the diagnosis starts from what's actually buyable, not from the integration's status light.
