Use caseWorkflow automation

Listing one catalog on Amazon, Otto, Kaufland and bol.com without the rejection loop

Maps one PIM catalog to each European marketplace's schema, writes localized titles and bullets, checks GPSR and EPR data, and works through rejections.

A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .

The short version

A workflow that takes product master data from your PIM or Shopify and turns it into listings each European marketplace accepts: attributes mapped to that marketplace's schema, titles and bullets written in its language and style, and GPSR safety and EPR registration data checked before anything is sent. It submits through the Amazon Selling Partner API or your feed tool, reads every rejection and proposes the fix. People approve product claims, regulated categories and hero SKUs.

Best for
Brands with a few hundred to a few thousand SKUs adding European marketplaces faster than the catalog team can map, translate and fix listings.
Connects to
Shopify, PIM (Akeneo or Plytix), Feed tool (ChannelEngine or Productsup), Amazon Selling Partner API, DeepL API, Google Sheets
The AI does
Maps free-text product data to each marketplace's allowed values, writes titles and bullets per marketplace and language, and reads rejection messages to propose fixes.
People do
Approve environmental, health and certification claims, sign off regulated categories and hero SKUs, and own the compliance data the system refuses to invent.
Built as
AI Workflow Automation, usually $15K - $30K

Every new marketplace is a new rulebook

Picture a home goods brand in Cologne with about 1,200 SKUs: bed linen, towels, cushions, candles, glassware and a small range of rechargeable LED lamps. Everything sells on Amazon.de today. This year's plan is Amazon.fr and Amazon.it, then Otto, Kaufland and bol.com. The product data lives in Akeneo, kept in good shape by one catalog manager, in German.

Each of those marketplaces wants the same products described differently. Amazon validates every submission against a schema for the product type. Otto and Kaufland have their own category trees and required attributes, and bol.com needs Dutch copy before anything else can happen. Even sizes do not travel: a 155 x 220 cm duvet cover is standard in Germany and an odd size in France, where shoppers look for 140 x 200 or 240 x 220.

Then there is the compliance data. Since 13 December 2024 the EU General Product Safety Regulation (GPSR) requires every online listing to show the manufacturer, an EU responsible person where the manufacturer is outside the EU, and warnings and safety information in the buyer's language. Packaging needs an EPR registration per country: a LUCID number in Germany, a unique identifier in France, where bed linen and towels also fall under the textile scheme. The lamps add WEEE and battery registrations.

None of this is hard to understand. It is hard to keep true across 1,200 SKUs, six marketplaces and four languages, which is why it lives in spreadsheets held together with manual syncs and patience.

The rejection loop, as it runs today

This is the loop the brand runs for every marketplace and every new collection. It restarts whenever a marketplace changes a template.

  1. Export the collection from Akeneo and copy the columns into the marketplace's category template, which names attributes differently and requires different fields from the last one.
  2. Paste titles and bullets into DeepL, then shorten them by hand to fit each marketplace's title rules.
  3. Look up EPR numbers, warnings and responsible person details in a separate compliance file, if anyone has filled it in for this product.
  4. Upload, wait for the processing report, and read errors such as a size value outside the allowed list or a required attribute left empty.
  5. Fix the failed rows, upload again, and meet the next error the first one was hiding.
  6. Weeks later, notice a suppressed listing, because a marketplace tightened a rule and the product quietly stopped selling.

The catalog manager's time is the visible cost. The larger one is a collection stuck in this loop for weeks instead of selling, or a listing live with the wrong size, which comes back as returns and one-star reviews.

How a product becomes a listing each marketplace accepts

The model does three jobs here: choosing values no lookup table can map, writing copy, and reading rejection messages. Whether a listing may go out is decided by code, and a missing compliance field is never filled in by the model.

  1. 01 Trigger · Akeneo API

    A product changes in the PIM

    A new product, a new locale, an edited attribute, or a marketplace switched on for a product family. A PIM webhook, or a nightly delta where there is none, creates one job per SKU and marketplace.

  2. 02 Plain code · Product Type Definitions API, feed tool

    Load the record and the target's rules

    Code pulls the product, its variants and EANs, and the target's requirements: for Amazon the product type definition, a JSON Schema per marketplace and locale; for the others, the feed tool's category template.

  3. 03 AI model · Structured output

    Map the values a lookup table cannot

    Most attributes map through tables the catalog manager edits. The rest are free text, such as 'Salbeigrün' or 'Leinenoptik', that must become one of the marketplace's allowed values. A small model picks from that list under a strict schema, or answers that nothing fits, which sends the value to a person.

  4. 04 AI model · LLM, DeepL API

    Write the copy for this marketplace

    A larger model writes the title, bullets and description in the target language from PIM facts only, following that marketplace's style sheet, length limits and the brand's glossary. It cannot add a material, a certification or a benefit the record does not contain. DeepL, with the same glossary, handles long descriptions.

  5. 05 Plain code

    Validate before anything is sent

    The payload is checked against the schema, then against the compliance rules in the table further down. A claims lexicon scans the copy in every language for words such as 'eco', 'antibacterial' or 'anti-mite' that need evidence on file.

  6. 06 Decision

    Can it go out without a person?

    Rules decide this per SKU and marketplace, never the model.

    • Schema valid, compliance complete, no flagged claim, category cleared for automatic submission then submitted
    • A flagged claim, a regulated category such as electrical goods, candles or food contact glass, or a hero SKU then the approval queue, with the flagged words highlighted
    • A compliance field is missing then blocked, with a task for the person who owns that data
  7. 07 Person

    Approve anything that commits the brand

    The reviewer sees the PIM record, the copy per language, the flagged words and the evidence on file, then approves, edits or rejects. Approvals are stored per claim and product, so a certification approved once is not asked about again for every colorway.

  8. 08 System · SP-API Listings Items, feed tool

    Submit exactly once

    Amazon listings go through the Listings Items API, first in validation preview mode and then for real; the other marketplaces go through the feed tool. Each job carries a hash of its content, so a retry after a timeout never produces a second submission, and an unchanged listing is never resent.

  9. 09 AI model · SP-API Notifications

    Read rejections and propose the fix

    Submission results, Amazon's listing issue notifications and the feed tool's error reports land in one queue. The model explains each error and proposes a fix. Pure mapping fixes are applied automatically; anything touching copy or compliance goes back to a person.

Every job is logged with the payload sent, the response and who approved what, which answers the question a market surveillance authority eventually asks: where did this listing's safety information come from?

One duvet cover on its way to Amazon.fr

What the job log shows for a single SKU. The function names are the build's own, and the results are shortened.

Job log, SKU BL-2231-SAL-155, target Amazon.fr

  1. pim.get_product(sku: "BL-2231-SAL-155")family bed_linen / 2 variants / de_DE complete, fr_FR empty / color 'Salbeigrün' / material '100% Baumwolle, Satin'
  2. map_value(attribute: "color", value: "Salbeigrün")base color 'green' from the allowed list / shade name 'vert sauge' kept for the title
  3. compliance.check(target: "FR")BLOCKED / French EPR identifier for textiles missing / task sent to the compliance owner
  4. Next morning the compliance owner adds the identifier in Akeneo, and the job resumes at the check.
  5. copy.write(target: "amazon.fr", locale: "fr_FR")title 124 characters / 5 bullets / glossary: 'satin de coton' / flagged: 'anti-acariens', a health claim with no evidence on file
  6. Catalog manager · Approval queue

    Take out anti-acariens, we never tested for that. The rest is fine.

  7. amazon.submit(sku: "BL-2231-SAL-155", mode: "VALIDATION_PREVIEW")INVALID / 1 issue: size given as text where this product type expects width and length with a unit
  8. rejections.propose_fix(issue: "size format")mapping fix: width 155 cm, length 220 cm, from the size table / applied automatically, mapping only
  9. amazon.submit(sku: "BL-2231-SAL-155", mode: "SUBMIT")ACCEPTED / submission stored with content hash 9f3c2e
Nothing on the listing was invented by the model. A person supplied the EPR identifier and removed the claim; the one automatic fix was a size format.

The checks every listing passes first

Validation is a list of rules the brand owns, not a prompt. Each rule names who clears a failure, so no blocked listing sits unowned.

SchemaThe payload validates against the target's current schema, fetched fresh and compared with the last version, so a new required field raises one alert per categoryThe system for mapping errors; the catalog manager for missing product facts
GPSR identityManufacturer name and contact address, plus an EU responsible person when the manufacturer is outside the EUCompliance owner
Warnings and safety informationPresent in the buyer's language, taken from approved translations, never translated on the flyCompliance owner, with a translator for new wording
EPR registrationA packaging number for every destination country that requires one, textile identifiers where they apply, WEEE and battery numbers for electrical itemsCompliance owner
ClaimsEnvironmental, health and certification wording needs evidence on file; a certification name needs a valid certificate numberProduct manager
VariantsThe parent and child structure fits the target's variation rules, and every child has its own EANCatalog manager
Claims deserve extra caution. From 27 September 2026 the EU bans generic environmental claims such as 'eco-friendly' unless the trader can show recognized excellent environmental performance, and a bullet point is the easiest place to make one by accident.

Where multichannel listings break

Feed tools show you these errors after the fact. This build is mostly about not producing them.

Sizes that do not travel

Bed, towel and curtain sizes follow national conventions, and marketplaces want them as structured values rather than text. Size mapping lives in a table the catalog manager edits per country and category. The model may suggest a new row; it never rewrites a size on its own, because a wrong size becomes a return.

Claims the model adds unprompted

Ask a model for persuasive bullets about cotton bed linen and 'breathable, hypoallergenic and sustainable' arrives without being asked. The lexicon catches such words in every language, including the model's own translations, and only claims approved against evidence can appear in a submitted listing.

Variant families that split

Amazon groups sizes and colors under a parent with a variation theme; other marketplaces model variants their own way, and a family valid on one can fail on another. A family is only submitted when every child validates, so half a family never goes live without the rest.

Rejection loops that never converge

Some errors hide others, and some fixes cause new ones. Each job keeps its full history, and after three failed attempts on the same SKU and marketplace it stops and goes to a person with that history, instead of resubmitting forever.

Copy that goes bland at scale

Six marketplaces in four languages is where every title starts to sound the same. A small evaluation set of reviewed titles per language and marketplace is rerun whenever a prompt or model changes, and a change that makes the copy worse does not ship.

Earning automatic submissions, one category at a time

This system writes to live marketplaces, so it earns that right in stages, per category and per marketplace.

AuditRuns every live listing and new SKU through the checks and reports what would fail. Nothing is written anywhere.The gaps it found are closed, and the catalog manager agrees with its findings
DraftMaps, writes and validates, then places each listing in the approval queue for a person to submit.Reviewers approve most drafts in a category without edits across a few collections
Automatic, per categorySubmits clean listings on its own in cleared categories, towels on Amazon.fr for example. Flagged claims, regulated categories and hero SKUs still stop for a person.First-submission acceptance for automatic listings stays at or above the manual baseline
Regulated categories never reach the last stage. For electrical goods, candles and food contact glass, a person signs off every new listing.

Is a feed tool enough, or do you need a layer that decides?

Start with what you already have. ChannelEngine, Productsup and Tradebyte are good at carrying product data to dozens of marketplaces, keeping stock and prices in sync, and showing channel errors in one place. PIMs such as Akeneo and Plytix now include AI features that draft and translate descriptions. If your categories are unregulated and you sell on two or three marketplaces, that combination is enough, and I would tell you to buy it.

What those tools do not do is decide. A feed tool maps fields the way you configured them; it does not know that 'anti-acariens' is a health claim or that a French listing lacks its textile EPR identifier. A custom layer earns its cost when the catalog runs to thousands of SKUs, regulated goods are in the range, three or more languages are involved, or fixing rejections has quietly become somebody's job.

The version I would build sits between the PIM and the feed tool rather than replacing either. The PIM stays the source of truth, the feed tool keeps distributing, and the custom layer does the mapping, copy, compliance checks and rejection handling in between. The same enriched data can later feed AI shopping assistants, as in the AI-readable catalog, and the approval queue can carry images from an on-model imagery pipeline.

How you would know it is working

A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.

First-submission acceptance
Share of listings accepted on the first submission, per marketplace and category, against the manual baseline from the months before.
PIM-complete to live
Days from a product being complete in the PIM to live on each marketplace. This is the number that says whether a new channel is actually open.
Reviewer edits
How often reviewers change generated copy, and what they change. Repeated edits of the same kind become a style-sheet rule or a glossary entry.
Blocked for compliance data
Listings stopped for missing GPSR, EPR or warning data, by owner and by age. It should fall close to zero after the first backfill and stay there.

What a build like this costs

This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.

What it costs to run

Token costs per listing are small, because mapping runs on a small model and only the copy uses a larger one: a collection of a hundred SKUs across six marketplaces is usually a few dollars to a few tens of dollars. DeepL's API is billed by character, and the PIM and feed tool keep their own subscriptions.

What moves the price

  • How many marketplaces and languages are in scope, and whether each marketplace gets its own style sheet
  • The state of the PIM: complete localized attributes, or German-only data with gaps the build has to surface first
  • How many regulated categories are included (electrical, candles, food contact, toys, cosmetics) and how much approved compliance text exists
  • Direct marketplace APIs such as SP-API, or a feed tool whose error reports the build has to read
  • Variant depth: sizes and colors per family, bundles and multipacks

Who this is for

  • Brands selling on one Amazon marketplace and adding Otto, Kaufland, bol.com or other Amazon countries
  • Fashion and home brands preparing the same product data for Zalando or About You alongside Amazon
  • Sellers of electrical goods, candles, cosmetics or textiles, where missing safety or EPR data blocks listings
  • Teams already on ChannelEngine or Productsup who still fix rejections by hand in spreadsheets

Questions people ask about this

How do I automate marketplace listings across Amazon, Otto and bol.com?

Keep one master record in the PIM, and put a layer between it and the marketplaces that maps attributes to each schema, writes copy per language, and validates compliance data before submitting. Distribution can stay with a feed tool such as ChannelEngine or Productsup. Rejections are read and answered with a proposed fix, and people approve anything beyond a mapping change.

Can AI translate Amazon listings well enough to publish?

For titles and bullets, yes, when it writes from structured product facts with a glossary and a style sheet per marketplace, instead of translating the German copy line by line. It should never translate regulated text on the fly: safety warnings and certification wording come from approved translations, and every generated claim is checked against a lexicon.

What does GPSR require on a marketplace listing?

Since 13 December 2024, the General Product Safety Regulation requires online listings to show the manufacturer's name and contact address, an EU responsible person when the manufacturer is outside the EU, information identifying the product including a picture, and any warnings or safety information in the buyer's language. Marketplaces ask for these fields and can suppress listings without them. This is an engineer's summary, not legal advice.

Do I need an EPR number for every country I sell in?

For packaging, in each country that requires registration, yes, and marketplaces check. Germany uses the LUCID register; France issues a unique identifier per EPR scheme, and textiles such as bed linen have their own scheme there. Electrical goods and batteries add more. The build treats these numbers as data a person owns: a listing without its number is blocked, never sent with a blank.

What does it cost to automate listings for five new marketplaces?

It usually lands in the multi-step tier of AI workflow automation, because it combines mapping, copy, validation, approvals and rejection handling. The number of marketplaces and languages, the state of the PIM and the share of regulated categories move it within that tier. Running costs are mainly tokens per listing, plus DeepL and the feed tool you may already pay for.

Sources