Uploading content via flat files — the bulk path that beats the single-edit UI.

Episode 09 covered the four upload paths Seller Central exposes and the contribution rules that decide which version of a field wins. Of those four paths, the inventory flat file is the one that earns its own episode. It is the only path that updates dozens or hundreds of ASINs in a single submission, the only place a small set of attributes can be edited at all, and the only upload mode whose feed-processing report tells you, line by line, which row failed and exactly which column and rule caused it.

The flat file is also the upload path most likely to cause damage when it is used wrong. Submit a full-update feed with empty cells where live values exist and Amazon dutifully blanks every one of those fields. Submit it without knowing the category template's required columns and the whole feed is rejected. This episode is the guardrail set that turns the flat file from a foot-gun into the safest bulk path in Seller Central.

Download the right template — category, not generic

There is no single "flat file." Amazon publishes a different inventory template for every product category, and the columns differ — a Shoes template has dozens of attributes a Kitchen template doesn't, and vice versa. The wrong template either drops your attribute values silently (no column to write into) or rejects the feed outright at the schema-validation step.

The path in Seller Central: Catalog → Add Products via Upload → Download an Inventory File. Pick the marketplace, then drill the category tree down to the leaf node that matches your product. The template that lands on disk is an Excel workbook with several worksheets:

• Instructions — read once per category; this is where Amazon documents attribute requirements, byte limits and the enum values some fields require.
• Data Definitions — every column, its data type, its allowed values, and whether it is required, preferred or optional. This worksheet is the single source of truth when a feed fails validation.
• Valid Values — the picklists for every enum field (item type keyword, target gender, country of origin codes, compliance flags). Free-text values in an enum column reject the row.
• Template — the worksheet you actually fill in. The header row is fixed; do not rename, reorder or delete columns.

Save the original template untouched as a master copy. Every feed gets a duplicate, named with the date and the marketplace.

The four columns that decide every feed

The Template worksheet has dozens or hundreds of columns. Four of them decide what the feed actually does:

• SKU (item_sku) — your internal identifier. Required on every row. This is the key Amazon uses to find the existing listing in your catalogue and decide whether to create or update.
• Product ID + Product ID Type (external_product_id + external_product_id_type) — GTIN / EAN / UPC / ASIN and the matching type code. Required when creating a new offer or attaching to an existing ASIN. Optional on a pure content update for an SKU that already exists.
• Update / Delete (update_delete) — controls the intent of the row. Update creates the listing if missing and overwrites every field present in the row. PartialUpdate only touches the cells you actually filled in — every blank cell is left untouched on the live listing. Delete removes your offer from the ASIN. The default of "Update" is the single most dangerous default in this entire template; switch deliberately.
• Feed Product Type (feed_product_type) — the category-leaf identifier. Required on creates, and required on updates that change attributes gated by category schema. Wrong value here rejects the whole row.

Update vs PartialUpdate — the cell that prevents catastrophe

The default mode of an inventory feed is Update: every column the template defines is treated as authoritative, and every empty cell on a row is treated as "Amazon should blank this field on the live listing." On a brand-new SKU this is fine — every field is in the row. On a content refresh of a 600-SKU portfolio it is a way to wipe out every attribute, bullet, search term or image- alt-text you did not personally re-type into every row.

PartialUpdate reverses the rule. The feed touches only the cells you filled in; every blank cell is ignored. Use it for any feed that isn't a clean-room SKU creation. The rule of thumb:

• New SKU launch → Update. Every field is in the row, every cell is the new live value.
• Refresh of an existing SKU → PartialUpdate. Only the columns you mean to change are filled. Everything else stays as the live ASIN had it.
• Single attribute fix across many ASINs → PartialUpdate. Fill the SKU, the one column you are correcting, and nothing else.
• Take-down → Delete. The feed-processing report is the receipt.

The column groups you actually fill in

Within the template, columns fall into recognisable groups. The clean workflow is to fill them top- down rather than left-to-right:

• Identity — SKU, external product ID + type, feed product type, update/delete mode, brand name, manufacturer.
• Title and copy — item_name, bullet_point1..5, product_description, generic_keywords (the 250-byte backend field from Episode 08).
• Category attributes — the dozens of category-specific columns the leaf node requires: target gender, item type keyword, size system, fabric type, capacity, fit type, voltage. The Data Definitions worksheet lists which are required vs preferred per category.
• Images — main_image_url plus other_image_url1..8 / swatch_image_url. Full HTTPS URLs to publicly accessible JPGs that match Amazon's image specs.
• Price & inventory — standard price, sale price, sale start/end, quantity, fulfilment channel. Often kept in a separate price/inventory feed rather than the content feed so the responsibilities don't collide.
• Compliance & safety — country of origin, hazmat flags, age restriction, regulated-product attestations. Required on creates in many categories; often edit-locked once set.
• Parent / variation — parent_sku, parent_child, relationship_type, variation_theme. The columns that stitch the variation family together, covered in Module 5.

Submitting the feed and reading the report

Once the workbook is filled, save the Template worksheet as a tab-separated .txt file. Upload via: Catalog → Add Products via Upload → Upload your Inventory File. Pick the matching file type ("Inventory File for [Category]"). Submit.

The feed runs asynchronously. Processing time is usually 5–30 minutes for small feeds, up to a few hours for large catalogues. The receipt is the feed-processing report, downloadable from the same screen. Three numbers on it matter:

• Rows submitted — sanity check that the file Amazon parsed has the row count you expected. A mismatch usually means a trailing blank row or an extra header row.
• Rows succeeded — anything less than 100% means rows were either rejected (hard error) or accepted with a warning (soft issue, but the row went live).
• Errors and warnings — every rejected row gets the SKU, the column, the error code and a human-readable message. Amazon's error codes (e.g. error code 8541, 8016, 90106) are stable; the same code for the same column always means the same thing.

The audit step is non-negotiable: every flat- file submission gets the processing report read in full before the feed is considered "done." Silent partial failures — 920 of 1,000 rows succeeded, 80 rejected — are the most common flat-file failure mode and the easiest to miss if nobody opens the report.

The traps the report won't catch

A "100% succeeded" report is not the same as "the live ASINs look right." Four traps slip past validation:

• Lost-update on a contribution-locked field. The feed processed, the field didn't actually change because a higher- priority contributor (Brand Registry, Amazon Retail) owns it. The processing report shows success; the live ASIN shows the old value. Catch with a post-upload diff against the live detail page.
• Empty-cell wipe under Update mode. Every successful row in an Update-mode feed blanked the columns you left empty. The report calls that a success. Catch by always using PartialUpdate for refresh feeds — the rule beats the audit.
• Wrong enum value silently accepted. Some enum columns accept any string and only fail at the SERP-filter step (the listing is live but doesn't get the category facet). Catch by cross-checking the Valid Values sheet during data prep, not after upload.
• Image URLs that 404 after the feed ran. Amazon fetches the image at processing time. A URL that worked at submission and went 404 ten minutes later leaves an empty image slot on the live ASIN. Host on a stable CDN, never on a temporary asset URL.

Where to use the flat file — and where not to

Use the flat file when the change is wide: dozens of ASINs, the same attribute or set of attributes, the same category template. A single-line content edit on one SKU belongs in the single-edit UI; a category-wide refresh of bullets across 200 ASINs belongs in a PartialUpdate feed. The cross-over is around 5–10 ASINs — below that, the UI is faster and lower-risk; above, the flat file pays for the setup.

Do not use the flat file as a replacement for the SP-API on a feed that needs to run unattended every day. Recurring price / inventory / content sync is the SP-API's job — flat files are the manual, audited path for scheduled human-driven updates.

What this episode hands off

The written copy is now live on the ASINs at scale, with a feed-processing report on file and a post-upload diff confirming the live detail page matches the brief. Module 8 continues from here into the A+ Content modules — the surface that replaces the description on every ASIN that has it live — starting with the foundations of what A+ actually is and which Amazon programs unlock which module set.