Retail Syndication: Getting Product Data Accepted by Lowe's, Home Depot and Menards

The job nobody writes about

Search "Shopify developer" and you get themes. Search "product data syndication to Lowe's" and you get vendor marketing.

But if you sell physical products at any scale, the hardest engineering problem you have is not your storefront. It is that the same product must exist, correctly and identically, in eight places at once: your own store, your wholesale store, Amazon Seller Central, Amazon Vendor Central, Lowe's, Home Depot US, Home Depot Canada, Menards, and the Kitchen & Bath channel.

I run exactly that for a US building-products manufacturer — 361 SKUs in the syndication set, fed from Shopify through Salsify out to six retail partners plus Amazon. Here is how it actually works.

The topology: Shopify is the source, the PIM is the distributor

The stable architecture is a straight line with one branch point:

• Shopify owns commercial truth — price, inventory, what is sellable, what is retired.
• Salsify (the PIM) owns descriptive truth — attributes, marketing copy, images, documents, certifications, and every retailer-specific mapping.
• Retailers consume from Salsify, each with their own template, their own required attributes, and their own idea of what a "product" is.

Getting this wrong in the obvious way — letting each retailer's portal become its own source of truth — is how brands end up with the same product described five different ways across five sites.

Direct channels vs export channels, and why it matters

Salsify channels come in two flavors, and confusing them is expensive:

• Direct channels publish straight to the retailer. Press the button and it is gone. Irreversible.
• Export channels produce a file you then load somewhere else by hand — a portal upload, a second PIM, sometimes an email attachment.

In practice the topology is messier than the docs suggest. One of our partners has no portal at all and consumes a spreadsheet by email. Another sits behind a second PIM in the middle of the chain — our PIM feeds their PIM which feeds the retailer. One channel labelled "direct" in the tool behaves as an export.

Verify what each channel actually does before you publish, not after. The button does not tell you whether it is reversible.

The data model trap: "variant" means two different things

This one has cost people entire catalogs.

Salsify is three levels — Style → Variant → SKU — with attribute inheritance flowing down from parents. Shopify is two levels — Product → Variant.

A PIM "variant" is a group of SKUs. A Shopify "variant" is a single PIM SKU. Same word, different cardinality. Map them naively and every relationship in your catalog is off by one level.

Worse, and this is the part that surprises people: PIM exports do not flatten inheritance. Export a SKU row and it comes out missing every value it was inheriting from its Style and Variant parents. If you have ever exported from a PIM, looked at half-empty rows, and assumed the data was missing — it was not. It was inherited and the export did not resolve it.

That is exactly why custom channels exist: a vendor-built mapping that resolves inheritance at publish time. Trying to export and hand-join in Excel is the long way around, and you will get it wrong on the products with the deepest hierarchy — which are always your best sellers.

Pricing rules that cost real money

Three rules I would tattoo on a new hire:

1. MAP must be byte-identical everywhere. Minimum Advertised Price is not a suggestion and not a per-channel experiment. A price that lands on one retailer and not the others is a defect. In Shopify terms: MSRP goes in compare_at_price (the struck-through number), MAP goes in variant_price (what is actually charged).

2. In a retailer's template, the field labelled "MSRP" usually means your MAP. This is not a typo on their end — retailers use the label to mean "the price shown on the site." Send true MSRP into that field and you will list your products meaningfully above your own store. One partner is the genuine exception and consumes both: MSRP as compare-at, plus a separate dealer cost.

3. Dealer cost is MSRP × the retailer's multiplier — not MAP × anything. Different retailers, different multipliers. Get this into a formula, not a hand calculation.

And a small one that fails silently: GTIN is the UPC with two leading zeros. Twelve-digit UPC, fourteen-digit GTIN. Send the UPC into the GTIN field and validation may accept it and matching will fail downstream.

Attribute requirements: the actual work

Each retailer publishes a template with required, recommended, and optional attributes. The engineering discipline is:

• Formulas before new properties. When a retailer asks for a field, the order of preference is: an existing property → a single static value → a formula derived from existing properties → and only as a last resort, a new property. Roughly 150 one-off per-retailer properties were built historically in this catalog and nearly every one is regretted, because each is a field somebody has to remember to fill forever.
• Position attributes in steps of 10. Display order 10, 20, 30 — so you can slide a new attribute in at 15 without renumbering the world.
• Mirror portal fixes back the same day. If someone fixes a typo in the Home Depot portal and not in the PIM, the next publish overwrites the fix. Silently. The portal is never the source of truth.
• Record ID is the import key. Export → fix in Excel → import is the bulk lever inside the PIM too, and no Record ID means no import.

Images: where completion scores lie to you

Image requirements differ per retailer — minimum dimensions, white background, naming convention, main-image-plus-N-alternates, sometimes a required lifestyle shot or a spec drawing.

Salsify gives you a completion score per channel. Learn to read it as a diff, not a grade. A score of 331 out of 361 after an image mapping run does not mean "94% good." It means 30 specific SKUs did not map, and the cause is almost always that one product family's asset filenames follow a different convention than the main line — an older product range, an acquisition, a supplier who names files differently.

Chase the 30. The number only matters as a pointer.

Every retailer has its own template, and that is the whole problem

There is no shared standard. Lowe's, Home Depot US, Home Depot Canada, Menards, Amazon and the Kitchen & Bath channel each publish their own workbook, and they disagree on almost everything that matters:

• Different required attributes per category. A shower base needs drain location and load rating at one retailer, and neither at another — but that one wants an ADA compliance flag the first has never heard of.
• Different units and formats. Inches as a decimal vs. a fraction vs. a string with the unit inside it. Weight in pounds vs. ounces. Yes/No vs. TRUE/FALSE vs. Y/N. A "23.5" that should have been "23 1/2" fails validation with a message about data type, not about fractions.
• Different category taxonomies. Your product is one thing; each retailer's tree calls it something else, and the required-attribute set is derived from their category, not yours.
• Different image specs. Minimum pixel dimensions, background requirements, how many alternates, whether a spec drawing counts as an image or a document, and file-naming conventions that must match the SKU in a specific way.
• Different file mechanics. Legacy .xls with three instruction rows above the header. XLSX with reserved rows the parser needs untouched. CSV in latin-1. Home Depot Canada wants French copy that the US template has no column for.

So a meaningful share of this job is exactly what it sounds like: taking each retailer's template, filling it correctly, fixing what they reject, and resubmitting until the catalog is live. It is not glamorous and it is the difference between a product being on a shelf and not.

The correction cycle: rejected → diagnose → fix → resubmit → approved

The loop is always the same four steps, and the discipline is in step two.

Rejected. The feed comes back with a status and, if you are lucky, a reason. Sometimes the reason is a row number and an error code with no field name. Sometimes it is "data standards not met." Sometimes it is silence and the item simply never goes live.

Diagnose. Never fix the row you were told about until you know the class of the error. The question is always how many other rows have this same problem? One rejected SKU with a missing certification attribute is usually forty SKUs in the same product family, and fixing one at a time turns a one-hour job into six weeks of round trips. I diff the rejected set against the accepted set on the suspect column — that comparison names the cause faster than any error message.

Fix at the source, not in the template. This is the rule that keeps the work from repeating forever. If the fix belongs in the product data, it goes into Salsify (or into Shopify and then Salsify). If the fix belongs in the mapping — a unit conversion, a category translation, a concatenation the retailer wants — it goes into the channel mapping or a formula, so the next publish is correct automatically. A fix typed directly into a downloaded template is a fix you will make again next month.

Resubmit and confirm. Resubmit only the corrected rows where the channel allows partial updates, and check the result against the live retailer page, not the portal status. Accepted and rendered are different states — I have had items pass validation, show green in the portal, and display with no images on the site for weeks.

Log the reason and its fix. Every rejection reason goes into a running table with the diagnosis and the resolution. The second time a code appears it should be a lookup, not an investigation. This single habit is what turns syndication from a permanent firefight into a maintainable process.

The most common causes, in the order I actually see them: missing required attribute for that retailer's category; wrong unit or number format; image below the minimum resolution or wrong background; GTIN/UPC mismatch (remember the two leading zeros); category mapped to a tree node with different requirements; description containing a competitor, a channel reference, or a URL; price outside the allowed MAP window.

Rejections and resubmission

Retailer rejections come back through the portal, sometimes by email, and — this is the important part — sometimes not at all.

Portal work queues (items to enrich, data-standards maintenance) sit there silently forever. Nothing pings you. Nothing appears in a dashboard. I have found items that had been waiting for months.

The mitigation is unglamorous and it works:

• A daily sweep of every retailer portal, filtered to items owned by us.
• A weekly spot-check of live retailer product pages against the PIM. The recurring finding is images that exist in the PIM and are simply not on the live page — published, accepted, and never rendered.
• A standing rule that "no news" is not "approved." An item is done when it renders correctly on the retailer's own site.

API reality check

Do not plan an automation strategy before you check what is actually available.

In this stack, the PIM's /products endpoint works with Bearer auth (Basic returns 401) and was good enough to bulk-verify all 361 records programmatically. But /channels and the organization root return 404 — so channel configuration and readiness work stay in the UI, permanently. And three of the six retailer platforms are browser-only with no API key at all.

So the honest architecture is hybrid: automate verification and file generation, accept that publishing on some channels is a human clicking a button, and put your engineering effort into making that human's job checkable rather than pretending it will disappear.

Keeping Shopify as the source of truth

The loop that holds it together:

• Shopify exports (via Matrixify) are the canonical list of what exists, what it costs, and what is sellable.
• The PIM is updated from those exports, never the reverse, for any commercial field.
• Descriptive enrichment happens in the PIM, because that is where the per-retailer mappings live.
• Every publish is preceded by a readiness check by attribute, not by vibe.
• Anything fixed downstream gets pushed back upstream the same day.

Why this is worth learning

There are a lot of people who can build a Shopify theme. There are very few who can get a product accepted by Lowe's, Home Depot, Menards and Amazon from a single source of truth and keep it accurate through a price change.

The second skill is where the leverage is, because a rejected SKU at a national retailer is not a bug ticket. It is a product that is not on a shelf.

I run Shopify → PIM → retailer syndication in production across Lowe's, Home Depot US and Canada, Menards, Amazon and Kitchen & Bath channels. If your catalog is fighting its channels, [let's talk](/shopify-expert) — or [hire me directly](/hire-shopify-developer).

Direct: [WhatsApp +55 11 98851-2788](https://wa.me/5511988512788) · [contato.matheusabrahao@gmail.com](mailto:contato.matheusabrahao@gmail.com)