Why marketplace listings get rejected when your product data is "complete"

A catalogue manager marks a product complete. Every required field in the PIM is filled. The listing is rejected anyway, or worse, it is accepted and then suppressed three weeks later.

Nothing was wrong with the product data. The mistake was in the word “complete”, which quietly means complete against my PIM’s schema and is being read as valid for this channel, in this market, in this language. Those are different questions, and only one of them has been asked.

The five ways a listing fails

1. A required attribute for the product type is missing. Requirements are per product type, not per catalogue. A “shoe” and a “safety shoe” are different types with different mandatory attributes, and a PIM that models “required” as a property of the field rather than of the (product type × marketplace) pair cannot represent that.

2. The identifier does not match. A GTIN that resolves to a different product in the marketplace’s catalogue than the one you are describing. This is the failure that looks most like a system error and is most often a data problem: a reused EAN, a variant that inherited its parent’s identifier, a supplier’s placeholder that was never replaced.

3. Title and bullet limits. Character limits differ per marketplace and per category, and truncation is not the only failure — some categories reject rather than truncate, and some reject on the presence of promotional wording rather than on length.

4. Image rules. Minimum dimensions, background requirements, what may appear in the main image. These are per category too.

5. Compliance fields. The newest class and the one growing fastest: GPSR responsible-person details, EPR registration numbers per market, hazardous-goods flags, and per-category safety documentation.

Why “complete in the PIM” is not “valid for the channel”

Because the schema is defined per marketplace, and often per category within it.

Amazon’s Selling Partner API models this explicitly. The Product Type Definitions API returns a JSON schema for a product type for a given marketplace — the marketplaceIds parameter is on the request, not an afterthought (v2020-09-01 reference). Amazon’s own documentation puts it plainly: the data for each ASIN differs by marketplace, because countries have different data requirements specific to that marketplace.

The schema is a per-marketplace artefact, not a per-region one — which is the part that catches teams out, because the mental model is usually “Amazon wants X” rather than “amazon.de wants X and amazon.fr wants Y”.

The clearest current example is GPSR. Regulation (EU) 2023/988 has applied since 13 December 2024 and requires, for products offered to EU consumers, an identifiable responsible person established in the Union. That obligation attaches to EU marketplaces. The attributes that carry it therefore exist on EU-facing product type schemas and not on others — so the same product, with the same PIM record marked complete, is valid on one store and invalid on another.

The same product needs different answers per market

Marketplace and market are not the same axis, and conflating them is where most homegrown validation quietly breaks.

amazon.de serves customers in Germany and Austria. Those are two markets with two sets of packaging and EPR obligations, and a product can be compliant for one and not the other while being listed exactly once. Under Directive 2008/98/EC as amended, extended producer responsibility is implemented nationally: separate registration, separate registration number, separate reporting. Germany’s Verpackungsgesetz requires LUCID registration; Austria’s regime is its own.

So the readiness question is not “is this product valid for amazon.de”. It is “is this product valid for amazon.de, for a customer in Austria, in German” — a rule resolved along three axes at once.

What a pre-submission check has to do

To be worth running, a check has to hold four things at the same time:

• A rule set per channel, versioned, because the marketplace changes it without asking.
• Resolution per market and per locale, not per channel alone — the amazon.de / Austria case above.
• A join to stock. A listing that is valid and has nothing behind it is a different problem, and finding both in one pass is the difference between one worklist and two.
• A result that names the fix, not just the failure. “Missing attribute” is a status code. “GPSR responsible person missing for AT — add on the variant, not the parent” is a task somebody can close.

Several PIMs do offer pre-submission validation — Salsify, Sales Layer and Akeneo among them — and it is genuinely useful. Where they tend to stop is the market axis and the compliance rows: validation against the channel’s schema is common; resolving the same product against two national EPR regimes behind one storefront is not.

Where TOVIA stands

The readiness engine is built and runs today on a local build against synthetic data — the rule sets, the per-channel resolution, the pass/fail with the attribute and the fix named.

The EU compliance attributes it checks — EPR registration per market, GPSR responsible person, CN code per variant — are in development. There is no live marketplace connector, so nothing submits anywhere yet.

What that means in practice: the part that decides whether a product is ready exists, and the part that knows what Austria requires is being built. Channel readiness has the detail, with the state of each piece on it.