Fix Catalog Identity Before You Write A+ Content

When an A+ submission bounces in Vendor Central and the error names the ASIN rather than the module, you are not looking at a content problem. You are looking at an identity problem: the brand string, the product ID, or the product type. Our agent audits all three across the catalog through the Selling Partner MCP, grounded by Amazon Agent Atlas on the amazon_vendors corpus, and it runs before a single module is written.

The ordering is the whole point. A+ content FAQ & troubleshooting traces the most common A+ error back to inaccurate listing data on the ASIN. So a team that writes content first spends seven business days finding out the listing was wrong, fixes the listing, and spends another seven finding out whether the content was. Two review cycles for one problem, and the first one told you the wrong thing.

Why not ask ChatGPT or Claude? A plain chat hits the same three walls on any Amazon job. It has no access to your data, so it cannot compare your ASIN's brand string to your Brand Registry record or see which barcodes collide. It has no way to take action, so it cannot read a listing, open a Support case, or submit a correction; every step is yours. And it runs on generic knowledge, not Amazon's, so it does not know that a registered-trademark symbol in a brand name breaks verification, or what Error 100873 means. You get disconnected, generic, manual work that arrives a week late. Each claim below hits one of those walls, and shows how the Selling Partner MCP (your catalog, plus the tools to act on it), Skills (the repeatable workflow), and Atlas grounding (the private rule book) get past it.

Brand verification fails on characters you cannot see

Brand guidelines is precise about what brand verification checks. When a brand name is updated, all attributes are verified, and the discrepancies to remove are exactly the ones that survive a visual review: the brand name is case sensitive and must be entered exactly as it appears in the Brand Registry application, and special characters such as the trademark and registered symbols have to be removed.

That is why this failure mode is so durable. Acme™ and Acme look like the same brand to the person checking the spreadsheet, and a trailing space is invisible in every tool anyone uses to look at it. Across six hundred ASINs, a hand check is not a plan.

The correction path matters just as much, and it is the reason to be honest about what automation does here. Once a brand has been submitted, you can request an update or deletion only by contacting Amazon: Contact us, then Manage my catalog, then Item detail edit, selecting Other product information and supplying the ASIN and vendor code. For multiple ASINs, Amazon points you at the Item maintenance form. That is a request workflow, not a write.

So the agent's job on this claim is not to silently repair a brand string. It is to find every ASIN whose brand attribute deviates from the Brand Registry name, character by character, and produce the populated request with the affected ASIN list attached. Detection at catalog scale, submission by a human.

Product IDs are unique, so most catalog errors are identity collisions

The barcode errors all come from one rule: a product ID, whether you call it a GTIN, a UPC or an EAN, can only be linked to one ASIN at a time. What differs is who else is holding it and why.

Error 100992 deserves separate treatment because it is the only one with a clock on it. The message tells you the barcode on the listing is incorrect and states the date by which Amazon will remove the listing, so it belongs at the top of a triage queue rather than in a catalog-hygiene backlog. Resolving it means supplying Selling Partner Support with the brand name, the current 14-digit barcode, and the replacement GTIN if one is needed.

That list is the useful part for automation. The evidence Support asks for is structured and knowable, which means an agent can assemble it for every affected ASIN at once rather than a person rebuilding it per ticket.

Product type has to agree with the product, and everything downstream depends on it

Error 101067 is the one that looks cosmetic and is not. It fires when the product type attribute disagrees with the rest of the details you supplied. Amazon's own example is entering Shirt as the product type on a listing whose title describes sunglasses.

The error itself is easy to read. The consequence is the part worth planning around: product type is what determines which attributes Amazon recommends for a listing, and the schema that a valid write has to satisfy. A listing filed under the wrong product type will therefore be audited against the wrong attribute set, pass that audit, and still be wrong. Fixing product type after an attribute audit means running the attribute audit again.

The bulk path has its own version of this. Troubleshoot errors in products uploaded by bulk spreadsheet documents that Product Type column values are pre-populated when the spreadsheet is generated, and editing them produces an error telling you to use the Vendor Central website instead. Other rows in that table follow the same shape: a value that was not taken from the provided drop-down is rejected, and a field marked non-editable has to be returned to its original value.

One loop, in order: identity, attributes, then content

Put together, the three surfaces have a strict dependency order, and running them out of order is what turns one problem into three review cycles.

Identity first. Brand string against Brand Registry, product IDs against collisions and brand ownership, product type against the product. Nothing downstream is trustworthy until these pass, and Error 100992 in particular is time-bound.

Attributes second. Only once product type is correct does the recommended-attribute set mean anything, because product type is what selects it.

Content last. A+ modules, imagery, brand voice. This is the only stage where the seven-business-day review clock applies, which is precisely why it should be the stage with the fewest unknowns left in it.

An agent runs that as one chained workflow rather than three projects owned by different people. It reads reconciled ASIN state through the Catalog Items API, resolves schemas through Product Type Definitions, writes what is writable through the Listings Items API, and splits out the cases that need a Support request with the evidence already assembled. Findings that are time-bound get ranked ahead of findings that are merely untidy.

What happens next

The artifact is a ranked identity report: every ASIN whose brand string deviates from Brand Registry, every barcode collision with the error code that will fire, every product type that disagrees with its own listing, split into what the agent can write and what needs a Support request with the evidence attached.

Saved as a reusable Skill, it runs ahead of the A+ pre-flight and the listing quality audit rather than alongside them, and re-runs on the listings-issue notifications the Amazon Agent Data layer subscribes to, so a barcode collision introduced next month surfaces the same week rather than at the next content push. Imagery regenerated through Amazon Agent Iris and reporting through the Vendor Central MCP sit on the same layer, alongside the Amazon Ads MCP when the question becomes what the fixed listings did to traffic. The reporting side of that picture is in the ARA report and metric glossary.

Seven business days is a reasonable price for a review of your content. It is an unreasonable price for finding out a barcode was wrong.

Next in this series: once identity is clean, deciding which attributes actually matter for each product type, and why the answer changes per type.