Marketplace feeds with Claude Code: from export to validation
Same catalog, but every channel wants its feed its own way: different field names, different formats, its own taxonomy and hard rejection rules. Here is how Claude Code maps catalog columns onto a channel's fields, fills gaps, validates types and values, and flags offers that will be rejected before you upload. On a copy of the data and with a diff review.
You prepare a product feed for Google Merchant or a marketplace with Claude Code in a few controlled passes: map catalog columns onto the fields the channel requires, fill gaps where they can be derived from the data, validate types and values (prices, currency, availability, image URLs, units), then flag the offers a channel will reject before you upload the file at all. Claude Code is an AI assistant that works on your files in the terminal, so it transforms the real export rather than text in a chat window, which we cover in more depth in our guide to Claude Code in eCommerce. One rule holds throughout: work on a copy of the export and review every difference before you save anything. Here is the full process and how to brief it.
Key takeaways
- A feed is not the same as a clean catalog. The catalog is the source; the feed is its translation into one channel's requirements: different field names, formats and its own taxonomy. Claude Code performs that translation on the real file, by rules you describe.
- AI feed automation pays off when it shifts errors left: you validate types and values and flag offers a channel will reject before you upload, not after Merchant Center hands you a list of disapprovals.
- Gaps that cannot be derived from the data, like a GTIN or a channel category for an ambiguous product, Claude Code flags rather than invents. You fill the correct value from a real source.
- The one safety rule: work on a copy of the export, keep the mapping under version control, review the diff before you save, and never put secrets or personal data in the files.
A feed is not the same problem as a clean catalog
It is easy to conflate two tasks that look alike but follow different rules. Cleaning a catalog tidies the source: splitting variants, validating codes, normalizing units and colors, removing duplicates. We covered it separately in the piece on cleaning a catalog CSV, and it is a good starting point, because no feed can rescue a messy catalog. Preparing a feed begins exactly where that ends: your data is already clean, but you have to translate it into the language of one specific channel. And every channel speaks a different language.
The same product, Google Merchant wants to see as an id, title, description, link, image link, availability, price and GTIN, with a category from its own taxonomy and attributes that depend on the product type. Another marketplace names those fields differently, expects a different price format or a different category list, and rejects an offer for a reason Google would never notice. That is why a single "universal" file does not exist. A feed is always a translation of the catalog into the requirements of one named channel, and that translation is exactly the repetitive, tedious work where Claude Code is useful.
What Claude Code does with a feed, and what it does not
The difference between Claude Code and a chat window comes down to one thing: a chat returns text you copy yourself, while Claude Code reads your export, proposes transformations, and after your approval writes the result to the file. It runs repetitive operations across thousands of offers as patiently as across ten, and that is its real value with feeds. It is not an oracle, though: it does not know your assortment better than you do, it does not know which channel category an ambiguous product belongs to, and it will not guess a GTIN that is not in the data. The boundary is sharp and worth holding: Claude Code flags and proposes, and it leaves any value that cannot be derived from the data to you. It will not invent a valid GTIN or the right category for a questionable product, and that is correct, because an invented feed value is either a disapproval or a silent error you only notice after sales drop.
Rule number one: work on a copy and version the mapping
Never transform the original export. Make a copy and work on that, and keep the mapping of catalog fields onto channel fields under version control (even a simple repository), so every rule change can be undone and compared. Do not put secrets into the files you share with the tool: API keys to your sales platform, tokens, or personal data. A product feed is one thing; a file with sensitive data is an entirely different decision. Claude Code reads exactly what you give it, so you decide what it sees.
How to brief it: input and expected output
The quality of the feed depends not on how "smart" the tool is, but on how precisely you describe the translation. Do not ask it to "prepare a feed for Google", because you will get someone else's reading of the spec. Instead describe three things: what you have on input (which catalog columns, in what state), what the output should look like (target channel fields, their names, format and separator), and the transformation rules (which catalog column maps to which channel field, how to format price and currency, how to map availability, how to build the image URL). One example works best: take one real catalog row and write next to it how that same product should look as a feed item, field by field. That example says more than a paragraph describing the spec.
To that you add one sentence worth repeating on every task: "show me the differences and flag anything you are unsure about instead of guessing". It turns a risky automation into a controlled process. You do not ask Claude Code for ready-made commands, or for it to decide what is required. You ask it to execute clearly stated rules and to flag reliably everything that needs your decision. You always take the channel field spec from the channel's own official documentation, and you are its source, because requirements and attribute names get updated, and the tool has no reason to know them better than the provider's current document.
The process, step by step
The steps below follow a natural order: from mapping the structure, through filling and validation, to flagging offers doomed to rejection. Run them in passes and check the differences after each one, rather than firing everything at once.
Map catalog columns onto channel fields
The starting point is a mapping table: which catalog column goes to which channel field, and in what form. You provide that mapping, and Claude Code rewrites the data into the target structure, renames fields, assembles composite values (for example a title from brand, name and variant by your rule), and drops columns the channel does not use. You check one thing: that every field the channel requires has a source in the catalog, and if it does not, that is the first list of gaps to resolve before moving on.
Fill gaps: GTIN, category, attributes
Some gaps can be derived from data you already have, and here Claude Code helps: it proposes a channel category from your internal category by your mapping, fills attributes computable from other fields, assembles a missing identifier by a rule. Some gaps cannot be derived, and that is the boundary you must not cross. A GTIN for a product that simply does not have one in the source, or a category for an ambiguous product, are values to fill from a real source, not to guess. Claude Code should collect them into a clear "for a decision" list, not fill them with a plausible-sounding value. An invented GTIN is not one gap fewer, it is one error more.
Validate types and values
Once the fields are in place, you check whether their contents make sense for the channel. Price has to be a number in the expected format with a currency, availability one of the allowed values, the image URL a valid link rather than a local path, units and dimensions in the format the channel expects. Claude Code walks the feed and flags fields that fall outside the type or the allowed set of values: a price written with a comma where a period is expected, empty availability, an image link without a protocol, a negative or zero stock on an offer marked as available. That is shifting errors left: you catch them in the file, not in the channel panel.
Flag offers that will be rejected
The last pass is the most valuable, because it touches money. Many rejections have repeatable, predictable causes: a field missing for a given product type, a conflict between fields (for example availability "in stock" on zero stock), a title or description breaking the channel length limit, no GTIN where the channel requires it and will not accept a brand-plus-manufacturer-number combination. Given the channel rules you describe, Claude Code flags the offers most likely to be disapproved for those reasons and groups them by cause. This does not replace validation on the channel side, but it lets you fix the most common rejections before the file even reaches Merchant Center or the marketplace panel.
Cheat sheet: problem in the feed, action, check
The whole process collects into one table. The right-hand column is the most important, because it is what keeps feed automation from turning one problem into another.
| Problem in the feed | What Claude Code does | What to check on its side |
|---|---|---|
| Catalog columns do not match channel fields | Rewrites data by your mapping, renames fields, assembles composite values | That every field the channel requires has a source in the catalog |
| Derivable gaps (category, attribute) | Proposes a value from data you already have, by the mapping rule | That the proposed category and attributes are right for ambiguous products |
| Non-derivable gaps (GTIN, doubtful category) | Flags as "for a decision", does not fill | That it flags rather than invents; fill from a real source |
| Wrong types and values (price, availability, image) | Flags fields outside the type or allowed set of values | That the type rules match the channel's current spec |
| Offers doomed to rejection | Groups offers by predictable disapproval cause | That the rejection rules come from official channel docs, not a guess |
| Conflicts between fields | Points out contradictions (e.g. availability vs stock) | Which field is true; fix the source, not just the feed |
The rule across the whole table: Claude Code flags and proposes; the decision on a value and on saving stays with you.
Before you upload the file: review the diff, not the result
Upload only after reviewing the difference. Before you send the feed to a channel, look at the difference between the export and the finished file (the diff): which fields changed, how many offers got flagged for a decision, how many are doomed to rejection and why. Do not judge by the final file alone, because it looks tidy even when half an offer quietly dropped out or a price went in the wrong format. Upload when the diff looks exactly as you expected and the "for a decision" list is empty or knowingly accepted. That is a few minutes that saves you from a wave of disapprovals and a suspended product account.
From a one-off export to standing feed automation
A one-off feed prep is a good start, but the catalog changes every day: prices, stock, new products, discontinuations. If you repeat the same mapping and the same validation by hand each time, you waste time on work that is repetitive by definition. The same rules (field mapping, filling derivable gaps, type validation, rejection detection) can be wrapped into a repeatable workflow that processes each new export by rules you set once, with the same diff review before sending and a separate feed per channel from a single source. That is exactly the work we take on at Seedlight in the AI Automation stage, and cover more broadly in our AI commerce automation offering: turning a one-off feed prep into a process that runs itself and leaves the human the decisions rather than the drudgery.
A good feed is not the goal in itself, only the condition for products to be listable and findable in every channel without a wave of rejections. Claude Code shortens the road from a raw export to a validated file from hours of manual fitting to a few controlled passes. The whole craft is in the discipline: work on a copy, describe the mapping and the rules instead of relying on the tool to guess, validate types and values on your side, and review the differences before you upload. The rest is just repeatability, and worth automating.
FAQ
How is preparing a feed different from cleaning a catalog?
Cleaning a catalog tidies the source: variants, codes, units, duplicates. A feed is the translation of a clean catalog into one channel's requirements: its field names, formats and taxonomy. They are two stages: first a clean catalog, then a separate feed per channel.
Will Claude Code fill missing GTINs on its own?
No, and that is the point. A valid GTIN is a specific value from GS1 or the manufacturer, not a number to guess. Claude Code flags offers without a GTIN and those where the channel requires one, but it will not enter an invented value. You fill the gaps from a real source.
How do you catch offers a channel will reject before upload?
You describe the rejection rules from the channel's official docs to Claude Code (required fields, length limits, conflicts between fields), and it flags the offers most likely to be disapproved and groups them by cause. This does not replace channel validation, but it catches the most common errors earlier.
Is this safe for my data?
Yes, if you follow the rules: work on a copy of the export, keep the mapping under version control, review the diff before sending, and never put secrets or personal data into the files. The tool reads exactly what you give it.
Journal
Co-founder of Seedlight · eCommerce platforms, AI, SEO and GEO
Newsletter
The Journal, straight to your inbox
New articles and lessons from real builds, every now and then. No spam, unsubscribe with one click.
