Uploading the copy into Seller Central — the four paths that actually land on the ASIN.

At the end of Episode 08 the keyword brief was fully placed: the title carried the head terms, the bullets carried the next synonym layer, the description either repeated the offer for the fallback surfaces or was left empty for A+, and the invisible 250-byte backend slot mopped up every remaining synonym. None of that work is live yet. The copy still has to be pushed into Seller Central, survive the contribution-rule logic that decides which version of each field wins, and not get silently overwritten by an older feed or another contributor on the same ASIN.

Seller Central exposes four upload paths for listing content. They look interchangeable from the outside; they aren't. Picking the wrong path for the size of the change is the single most common reason a finished brief never makes it onto the live detail page.

The four upload paths, ranked by scale

From smallest change to largest, the four paths are:

• The single-edit UI in Seller Central's Manage Inventory → Editview. Field-by-field, one ASIN at a time. Right for one-off fixes and the first manual setup of a single product.
• The inventory flat file — the category-specific Excel template downloaded from Inventory → Add Products via Upload. Right for any change touching more than a handful of ASINs, anything that needs a header column not exposed in the UI, and anything that has to be repeatable.
• Build International Listings (BIL) — the source-marketplace → target-marketplace sync. Right for rolling out a finished brief from a "home" marketplace to additional EU marketplaces without re-writing the listing five times.
• The SP-API / Listings API — partner-tool or in-house integration. Right for ongoing catalogue management at scale, for tooling that has to write back the same fields on a schedule, and for everything that has outgrown the flat-file upload cadence.

The decision rule is simple: use the smallest path that fits the change. The UI for a single typo. The flat file for a brief. BIL when the same brief has to go to four marketplaces. The API only when a tool already owns the field.

Path 1 — the single-edit UI

Open Manage Inventory, find the ASIN, click Edit, and Seller Central renders the detail-page fields grouped into the same tabs the flat file uses: Vital Info, Variations, Offer, Compliance, Images, Description, Keywords, More Details. Title, bullets and product description sit under Description. Backend search terms sit under Keywords → Search Terms. Attributes used as filter facets sit under More Details.

Three field-level traps catch first-time editors:

• Bullet point fields are HTML-stripped on save. Bold tags, line breaks and any markup paste from a Word doc are removed. Write or paste plain text only; format with capitalisation and emoji if the category allows them, not with HTML.
• The product-description field tolerates a narrow HTML subset — line breaks (<br>) and paragraph tags survive on most categories, almost everything else is stripped. Run the description from Module 8 Episode 07 with <br>breaks at the ~160-character white-space rule, not free-form markup.
• The Search Terms box is a single string, not a list of slots. Paste the finished 245-byte token stream from Episode 08, single spaces, lowercase, no commas. Seller Central shows a character count, not a byte count — verify in your listing tool first.

Path 2 — the inventory flat file

The flat file is the single most important upload path in Seller Central, and the one almost every production listing eventually lives on. Download the category-specific template from Inventory → Add Products via Upload → Download an Inventory File, fill the Templatetab, save as a tab-delimited .txt, and upload it under Add Products via Upload. Amazon processes the file asynchronously and returns a per-row processing report — read it. The processing report is the only reliable signal that a row landed.

The columns the Module 8 brief maps onto:

• item_name — the title from Episode 05.
• bullet_point1 through bullet_point5 — the bullets from Episode 06.
• product_description — the description from Episode 07 (or left blank if A+ has fully replaced it).
• generic_keywords — the 245-byte backend token stream from Episode 08.
• intended_use1…n, target_audience1…n, subject_keywords1…n — the neighbouring backend slots that also feed indexing.
• Category-specific attribute columns — material, finish, capacity, compatibility, sport, occasion — every one of which can surface as a SERP filter facet.

Two flat-file rules save weeks of debugging:

• Use the Partial Update file type for content edits. Set theupdate_delete column to PartialUpdate on every row. Without it, blank cells in your file overwrite live values on the ASIN as "intentionally empty" — silent data loss.
• Always work from a freshly downloaded template. Amazon adds, renames and retires columns category by category. Editing an old template can submit rows under a deprecated header that the new validator rejects, and the processing report blames the row, not the template version.

Path 3 — Build International Listings

BIL is the one-to-many path. Set a source marketplace (typically the marketplace the brief was written for), pick the target marketplaces, and Amazon syncs catalogue data from source to target on a recurring schedule. Pricing rules are configurable per target; content (title, bullets, description, images, attributes) mirrors the source unless explicitly overridden on the target.

BIL is the right path for rolling a finished EU brief across DE → FR/IT/ES/NL/PL/SE without re-uploading five flat files. It is the wrong path when the brief itself has to be localised — translated, retargeted at local search habits, or rebuilt against a local category's style guide. In those cases, mirror only the offer and images via BIL and write the content fields fresh per marketplace.

The trap: once BIL is active for a target, any manual edit on that target marketplace will be overwritten on the next sync unless the edit was made on the source marketplace too. Editors on the target marketplace need to know BIL is running; otherwise they spend an afternoon fixing a title that re-reverts overnight.

Path 4 — the SP-API Listings endpoints

The SP-API Listings Items endpoint writes the same fields the flat file writes, on a per-attribute granularity, with an immediate per-request status response instead of a batched processing report. It is the right path when a tool already owns the field — a PIM, an AMALYZE-style listing platform, an in-house catalogue manager — and the upload cadence is continuous rather than periodic.

The API doesn't change the contribution-rule logic that decides which version of a field wins (see below). It just makes the write fast and machine-auditable. For most teams not running an in-house integration, the flat file is the correct path until the catalogue outgrows it.

The contribution-rule trap — whose copy actually wins

This is the single most-misunderstood piece of Seller Central. Amazon's catalogue is shared — multiple sellers can contribute to the same ASIN, and Amazon's catalogue engine picks which contributor's value is shown per field based on a contribution score. Brand Registry contributions carry the heaviest weight, then GS1-verified contributions, then repeat contributions, then everything else.

Practical consequences when you press Save:

• On a brand you own and have registered, your contribution wins for the brand-owned fields — title, bullets, description, images, A+ Content. The upload becomes live within minutes.
• On a brand you don't own but resell, your contribution is recorded but typicallyloses to the brand owner's. The listing appears unchanged after upload — not because the upload failed, but because Amazon chose the higher-trust contributor's value to render.
• On a brand-new ASIN with no prior contributions, the first complete contribution tends to win until a higher-trust one arrives. New-ASIN setup is the one moment a non-brand-owner can decisively shape the detail page.

The audit step that catches this: diff the live detail page against the brief 24 hours after upload. If a field shows the old value, the upload didn't fail — the contribution lost. The fix is brand-registry or GS1 documentation, not another upload.

Vendor Central — the same fields, a different door

Vendors don't have Seller Central's single-edit UI for content. The equivalent paths are:

• Item-setup form in Vendor Central — the closest analogue to the UI edit, one ASIN at a time, with a 24–72 hour propagation lag and occasional rewrites by Amazon's catalogue team.
• Catalogue feed via Vendor Central's bulk upload — the analogue to the flat file, with the same per-row processing report on a slower cadence.
• The Vendor Direct Fulfillment / Retail Analytics API for partners with API access.

The contribution-rule logic still applies on the Vendor side, but Vendor contributions sit at a higher tier than most Seller contributions on ASINs sold both 1P and 3P — Vendor edits usually win on co-listed ASINs.

The post-upload audit

Treat upload as a step, not the finish line. The five-minute audit checklist after every brief goes live:

1. Open the live detail page in an incognito window — never just the Seller Central preview.
2. Diff title, bullets and description against the brief, character by character.
3. Confirm the new main image and gallery order rendered.
4. Search the backend token list against a test query that should newly index (use theBrand Analytics Search Terms report48–72 hours later for the actual indexing signal — the live page won't display the backend field).
5. Check that any deprecated value (an old bullet, an outdated attribute) was actually replaced and not just appended.

Anything the audit catches goes back through the smallest path that fits the fix — usually the single-edit UI for a one-line correction, or a targeted partial-update flat file for anything broader.

What this episode hands off

Episode 09 turns the finished brief into a live detail page. From here, Module 8 continues into the higher-surface content the upload path opens up: A+ Content modules, A+ Premium, Brand Story 1.0 and 2.0, and the Brand Store — all of which live on the same ASIN but go through their own contribution-rule logic and their own upload cadence.