Product Content Syndication Software: Why the Same Item Gets Rekeyed for Every Retailer

Why content, not stock, is what keeps items offline

A brand sets up a new item. It goes to Amazon, Walmart, Target, Kroger, Instacart and four regional grocers. Each one wants a different title length, a different attribute set, a different taxonomy node, a different image specification and a different enrichment threshold before the item is considered ready to publish. Somebody in ecommerce operations opens a spreadsheet template per retailer and fills it in from the master item record, changing the title each time to fit the character limit and reordering the attribute columns.

Then the rejections come back. One retailer bounced the item because the case pack dimensions failed a validation. Another accepted it but flagged the main image for having a lifestyle background where they require the product on white filling most of the frame. A third accepted everything and the item still is not live because a taxonomy node was chosen that the retailer deprecated last quarter. Those rejections arrive in three different places: a CSV in a portal, an email, and a queue in a syndication tool nobody logs into.

The item is not on sale. That is the cost, and it is a direct one. Stock is sitting in a distribution centre, a promotion is scheduled, and the listing is dark because an attribute failed a rule nobody in your business can see.

Problem 1: one item, twelve schemas, no shared model

The core difficulty is that every receiver defines the same product differently. Net content is one field to one retailer and three fields to another. Colour is free text here and a controlled list there. Ingredients and allergen statements have their own structures for grocery. Electrical goods need certification fields that a food retailer has never heard of. Sizes, pack configurations and units of measure all diverge.

Salsify and Syndigo genuinely maintain these connections and readiness rules, and you should not rebuild a connector for the sake of owning it. Where they cost you is the shape of the work they leave behind. Their readiness rules are their interpretation of each receiver's requirements, so when your item fails you are debugging their model of the retailer rather than the retailer. Any attribute your category needs that is not in their model becomes a custom field with no validation behind it, which means it flows through unchecked. Akeneo is a capable product information manager and its syndication side is thinner, so you end up with a good internal catalogue and a manual channel process. 1WorldSync is strong specifically on GDSN and grocery data pools and correspondingly narrower outside that. All of them price by items or channels, so a large catalogue across many receivers becomes a serious annual line whether or not the items are selling.

What a custom build does: hold one canonical product model that is genuinely yours, with the attributes your categories actually require and validation that reflects your own product knowledge. Then define each receiver as a transformation: field mapping, value mapping, taxonomy mapping, unit conversion, and a rule set that must pass before submission. Adding a receiver becomes writing a transformation rather than reshaping your catalogue.

Problem 2: rejections are a queue nobody owns

Rejection handling is where syndication programmes actually fail. A rejection is not an error, it is a task: someone must interpret a coded reason, fix the underlying data, and resubmit. If rejections land in a vendor's interface, a portal and an inbox, no single person sees the whole picture and items quietly stay dark.

What a custom build does: normalise every rejection reason into your own taxonomy and route it to the person who owns that data, not to a generic ecommerce inbox. A dimension failure goes to the person who owns packaging data. An image failure goes to the studio queue. A missing regulatory attribute goes to compliance. Then measure the thing that matters, which is not a content health score but time to live per item per receiver, and the list of items that have been unpublished for more than a week. That list is a revenue report and it should be reviewed like one.

Problem 3: images and video are half the requirement and are treated as an afterthought

Retailers specify main image rules precisely: product on a plain background filling most of the frame, no added text or graphics, minimum pixel dimensions, permitted file types. Secondary images have their own conventions. Some receivers want specific aspect ratios, some want video, some want a size chart or a nutrition panel image with legible text at thumbnail scale.

Storing one high resolution master and manually producing variants per receiver is how most brands work, and it does not scale past a few hundred items. Worse, the manual step means the rules get applied by memory and the failures are found by the retailer.

What a custom build does: derive every receiver variant from the master automatically, with crop, resize, format conversion and background handling as a defined pipeline per receiver. Then check before submission rather than after: is the background acceptable, does the product fill enough of the frame, is there text overlaid where text is prohibited, is the resolution sufficient after the crop. Automated image checking is a well suited machine learning problem and it belongs here, catching the failures that otherwise come back as rejections a week later. Route uncertain cases to a human rather than blocking, because a false positive that stops a launch is worse than the rejection it prevented.

Problem 4: copy has to be rewritten per receiver and the rewriting never keeps up

A title with a 200 character allowance on one marketplace and 80 on another is not the same title truncated. Bullet points have different counts and different tone conventions. Some receivers prohibit promotional language or claims that others expect. Grocery receivers want the regulated content, meaning ingredients and allergens, exactly as it appears on pack.

What a custom build does: separate regulated content from marketing content and treat them completely differently. Regulated content is generated from the product record and must never be edited by a copywriter or a model, because that content has to match the pack. Marketing content is generated per receiver within that receiver's constraints, and this is a good use of a language model: produce a compliant title and bullets within the character limits and the prohibited terms list, then route to a human for approval on new items and let low risk updates flow. The distinction between the two content types is the important design decision. Blur it and you will eventually publish a generated allergen statement, which is the one failure in this whole category that is genuinely dangerous.

Problem 5: GDSN and portal submission are different worlds and both are yours

Grocery and mass receivers largely expect data through a GS1 data pool, with GTIN based identification, hierarchy relationships between each unit, case and pallet, and validation rules that are strict about measurement and packaging attributes. Marketplaces and direct portals expect flat files or API submissions with their own identifiers. A brand selling to both is running two fundamentally different publication models from one catalogue.

What a custom build does: model the packaging hierarchy properly once, because GDSN forces a discipline that portals do not, and portals then consume a flattened view of the same truth. Retailers who go the other way, starting flat and bolting a hierarchy on for GDSN, spend the next two years reconciling case dimensions that exist in two places and disagree.

What this costs and how long it takes

A focused first release, meaning the canonical product model with real validation, transformations for your three largest receivers, the rejection queue with routing by data owner, and image variant generation, runs $60,000 to $140,000 and ships in 10 to 16 weeks. A full platform adding GDSN publication, automated image checking, per receiver copy generation with approval, a supplier or brand facing intake portal if you are a distributor, and readiness reporting by time to live runs $160,000 to $400,000 phased over 6 to 12 months.

What drives cost up in syndication specifically: the number of receivers, since each is a genuine mapping and rules project; whether GDSN is in scope, because data pool certification and hierarchy modelling is its own workstream; catalogue volatility, since a brand launching hundreds of items a season needs intake workflow that a stable catalogue does not; and how many source systems your product data actually lives in today, which is usually more than the person commissioning the project believes. What keeps it down: three receivers, one category, and keeping any existing syndication subscription running in parallel until your own pipeline is proven on live items.

Build versus buy, and when buying is the right call

Buy Salsify or Syndigo if your receiver list is mainstream, your catalogue is a few thousand items, and your attributes fit their models. The connections are maintained, the readiness rules are updated when retailers change requirements, and that maintenance is real work you would otherwise own. Buy 1WorldSync if your world is almost entirely GDSN. Buy Akeneo if your actual problem is internal product data governance and syndication is secondary.

Build when two or more of these are true. Your categories need attributes and validations that no packaged model carries, which is common in regulated, technical and industrial products. You sell to receivers no vendor prioritises, meaning regional grocers, distributors and international retailers where you are stuck with manual templates anyway. Your catalogue is large enough that per item pricing has become a serious annual cost with no corresponding service. Your rejection queue is unowned and items regularly sit dark for weeks. Or you are a distributor or marketplace operator receiving content from hundreds of suppliers, which is the inverse problem and is almost never served well by tools built for brands publishing outward.

The honest tipping point is where the work sits. If most of your effort is in maintaining connections, buy. If most of it is in transforming, validating and fixing your own data before it reaches those connections, that work is yours regardless of what you buy, and building it gives you a model you control.

How to choose a developer for content syndication software

Ask them how they model packaging hierarchy. If they cannot describe the relationship between each unit, inner, case and pallet with their own identifiers and measurements, GDSN will defeat the project later and your case dimensions will disagree with themselves.

Ask how regulated content is protected. The correct answer separates ingredients, allergens and mandatory declarations from marketing copy entirely, with generation and editing blocked on the regulated side. If a developer proposes running everything through the same content generation pipeline, that is a serious design flaw rather than a preference.

Ask what happens to a rejection. You want normalisation into your own reason taxonomy, routing to the person who owns that data, and a time to live measure. An answer that stops at displaying the retailer's raw error message rebuilds the queue nobody clears.

Ask who owns the code, the mappings and the product data, and settle it before kickoff. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit. Your receiver mappings represent years of accumulated knowledge about how each retailer actually behaves, and that is exactly the asset a vendor lock in strategy is designed to capture.