Product Content Syndication Software Problems: The 5 That Keep Items Offline, and How to Avoid Them

Why does rebuilding the channel connectors waste the budget?

It is the obvious first move and it is usually the wrong one. A team frustrated by a syndication subscription decides to own the whole path, scopes connectors to the major marketplaces and data pools, and spends the first four months rebuilding pipes that already worked.

Salsify and Syndigo genuinely maintain those connections and the readiness rules behind them, and that is real recurring work: retailers change requirements, deprecate taxonomy nodes and adjust validations, and somebody has to keep up. Rebuilding a marketplace connection or a data pool interface for the sake of owning it wins nothing, and the maintenance burden transfers to you permanently.

The work that is genuinely yours sits behind those connections: the canonical product model with validation reflecting your own product knowledge, the transformation rules per receiver, the rejection handling, and the image and copy pipelines. That work exists regardless of which pipes you rent.

The tipping point is where your effort sits. If most of it is in maintaining connections, buy. If most of it is in transforming, validating and fixing your own data before it reaches those connections, build that layer and keep the connections you already pay for. Scope a first release as the canonical model, transformations for your three largest receivers and a routed rejection queue, and keep any existing subscription running until your own pipeline is proven on live items.

What goes wrong with packaging hierarchy and scattered source data?

Two data problems account for most of the pain, and both are decided in the first week of modelling.

The first is packaging hierarchy. Grocery and mass receivers largely expect data through a GS1 data pool, with identification at each level and relationships between the unit, the inner, the case and the pallet, plus validation rules that are strict about measurement and packaging attributes. Marketplaces and direct portals expect a flat record. Brands that start flat and bolt a hierarchy on later spend a long time reconciling case dimensions that exist in two places and disagree, and disagreeing case dimensions are one of the most common causes of a rejection that looks like a mystery.

The second is source count. Product data almost always lives in more places than the person commissioning the project believes: the enterprise system holds dimensions and pack configurations, a marketing system holds copy, an asset library holds images, regulatory holds ingredient and allergen data in a document, and a spreadsheet holds the attributes nobody else would store. Consolidating those is discovery work, because each source has an owner who has to agree what the authoritative version is.

What works: model the hierarchy properly once, because a data pool forces a discipline that portals do not, and let portals consume a flattened view of the same truth. Then inventory every source and assign a single owner per attribute before writing transformations, so the canonical model has one authoritative answer rather than a merge rule.

Why do retailer requirements break your feed after launch?

Because a receiver's requirements are a moving specification maintained by a team that does not know you exist, and the change is rarely announced in a form you receive.

Taxonomy nodes get deprecated, so an item categorised correctly last season sits under a node that no longer accepts submissions. Title character limits change. An image specification is tightened around frame fill or background. A validation on packaging measurements becomes stricter. None of this is unreasonable on their part, and all of it arrives at your feed as a rejection code, item by item, weeks after a launch window has passed.

What works: treat every receiver as a versioned profile holding its field mapping, value mapping, taxonomy mapping, unit conversions and the rule set that must pass before submission, so a requirement change is an edit to a profile rather than a code change. Run the rules before you submit rather than relying on the receiver to tell you, because a pre submission failure costs minutes and a rejection costs a week. And keep the submitted payload exactly as sent alongside the response, because when a receiver's behaviour changes, the diff between what passed last month and what failed this month is the fastest available diagnosis.

What happens when regulated content and rejections are not owned?

These are the two gaps that turn a technically working pipeline into an operational problem, and one of them is genuinely dangerous.

Regulated content is the serious one. Ingredients, allergen statements and mandatory declarations have to match what is printed on the pack. If they flow through the same generation and editing path as marketing copy, somebody will eventually publish a generated allergen statement. That is the one failure in this category with real consequences, and the design decision that prevents it is separating the two completely, with generation and free editing blocked on the regulated side and values derived from the product record.

The rejection gap is the commercial one. Without an owner, rejections accumulate in three systems and items stay dark. The measure that fixes it is not a content health score, which tracks conformance to a vendor's model rather than commercial outcome. It is time to live per item per receiver, plus the list of items unpublished for more than a week, which should be reviewed as seriously as an out of stock report.

What to build: normalise every rejection reason into your own taxonomy and route it to the person who owns that data. A dimension failure goes to whoever owns packaging data. An image failure goes to the studio queue. A missing regulatory attribute goes to compliance. A generic ecommerce inbox is where rejections go to be ignored.

Should you build custom or configure what you already own?

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, 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 data pool publication to grocery and mass receivers, because that is what it is built for and it is narrower elsewhere by design. Buy Akeneo if your actual problem is internal product data governance and syndication is secondary, and accept that its syndication side is thinner so the channel process stays partly manual.

Where these cost you is the shape of the work they leave behind rather than the software itself. Readiness rules are a vendor's interpretation of each receiver's requirements, so when an 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, so it flows through unchecked.

Build when two or more of these are true. Your categories need attributes and validations 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. Per item pricing has become a serious annual cost with no corresponding service. Your rejection queue is unowned. Or you are a distributor receiving content from hundreds of suppliers, which is the inverse problem.

How do hidden costs get into the quote?

Five items, the first scaling with your ambition.

• Receivers, priced individually. Each is a genuine mapping and rules project, not a configuration toggle. A simple flat file receiver is days. A data pool or a portal with unusual validation is several weeks.
• Data pool certification. If publication to a GS1 data pool is in scope, certification and hierarchy modelling is its own workstream, and the calendar belongs to the data pool.
• The image pipeline. Deriving every receiver variant from a master with crop, resize, format conversion and background handling is more engineering than it looks, and automated pre submission checking adds a review path for uncertain cases.
• Intake workflow for a volatile catalogue. A brand launching hundreds of items a season needs validation at the door that a stable catalogue does not, and this is usually discovered after the transformation layer is built.
• Source system count. Consolidating product data across the enterprise system, marketing, the asset library, regulatory documents and spreadsheets is discovery time with other people's calendars in it.

What keeps it down: three receivers, one category, and running the existing subscription in parallel until the new pipeline has published live items successfully.

What separates a syndication build that works from one that fails?

Four things, and each is a direct question to ask a developer.

Ask how they model packaging hierarchy. If they cannot describe the relationship between the unit, inner, case and pallet with their own identifiers and measurements, a data pool will defeat the project later and your case dimensions will disagree with themselves in two systems.

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

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 how image compliance is checked before submission rather than after. Automated checking of background, frame fill, resolution after crop and prohibited text overlays is a well suited machine learning problem, and it belongs before the file goes out. Route uncertain cases to a human rather than blocking, because a false positive that stops a launch is worse than the rejection it prevented.

Then settle ownership of the repository, the infrastructure accounts, the canonical model and every receiver mapping in writing before kickoff. At Digital Heroes the client owns all of it from the first commit. Those mappings encode years of knowledge about how each retailer actually behaves rather than how its documentation says it behaves, which makes them the most easily captured asset in this category.