This is Amazon's catalog record for the ASINs you sell, as it stands on the day you ask. It is not a Reports API file: it comes from the Catalog Items API, one item resource per ASIN, and that resource carries several sections at once, so the file lands as six tables joined on asin (and reported_marketplace_id).

The report's own table, the master spine, is one row per ASIN per marketplace. It flattens the identity sections: product_type; the external identifiers ean, upc, gtin and isbn (several of one type are comma-joined into a cell); the VARIATION relationship as parent_asins, relationship_type, variation_theme and variation_attributes; the browse classification as a leaf (classification_id, classification) plus the parent chain walked root to leaf in classification_path; and the two sales-rank families, sales_rank within sales_rank_title and display_group_rank within display_group_rank_group. Each rank is the headline rank by construction: the lists arrived with at most one entry per family, and only the first is kept.

Five companion tables hang off it. Summaries is again one row per ASIN per marketplace with the descriptive fields: brand, item_name, manufacturer, model_number, part_number, color, size, style, the summary's own browse_classification, website_display_group, package_quantity and four flags. Dimensions carries up to two scopes, item_ and package_, each with height, length, width and weight as a float with its unit in the column beside it; an ASIN whose catalog entry has no dimensions still gets a row, with every measurement null. Images is one row per rendition: variant (MAIN and PT01 to PT08 observed), link, height, width, several sizes per variant. Attributes explodes the product-type attribute blob one row per element, in the same format as the listings attributes table: attribute_name, attribute_index, language_tag, value, value_json. Vendor details (brand_code, product_group, product_category, replenishment_category and so on) is populated only for vendor accounts and header-only for everyone else.

Everything is Amazon's current catalog state and mutates in place. There is no date range on any row, only the snapshot date the pull was made.

There is no report type for this data in the Reports API or in Data Kiosk. It comes from the Selling Partner API's Catalog Items API (v2022-04-01) through the synchronous searchCatalogItems operation. You pass up to twenty identifiers per call and the marketplace, and ask for the includedData sections you want. Amazon's enum for the operation is attributes, classifications, dimensions, identifiers, images, productTypes, relationships, salesRanks, summaries and vendorDetails; ask for nothing and you get summaries alone. Each call answers the same item resource as the per-ASIN getCatalogItem, so one batch loop replaces thousands of single calls.

The trap is that the catalog has no dump operation. It is Amazon's catalog, not your account's, so nothing will hand you "all my items"; something has to say which ASINs to ask about. The usual list is the account's own listed ASINs, which is why the file covers your catalogue — but the list is an input to the call, so coverage is only ever as complete and as current as whatever list you feed it.

The second trap is vendorDetails. A seller credential that requests it gets an InvalidInput error reading "FORBIDDEN, requires vendor access", and the whole call fails with it. Request that section only when the account is a vendor. Vendors, for their part, answer every other section too.

Each section in the response is a list with one element per marketplace, and every element names its marketplaceId. One search call covers one store — Amazon's reference gives marketplaceIds on searchCatalogItems a Max count : 1 — so covering several stores means one call per store, and each row is stamped with the marketplace its call requested. Widening a pull to several marketplaces therefore means more calls, and more rows, not dropped ones.

Whether any Seller Central page offers an equivalent export is not something the evidence here establishes, and no Amazon help page describing one turned up. The API is the only path this page can vouch for.

Main table

summaries

dimensions

images

attributes

vendor_details

Auditing variation families. Group the spine on parent_asins and compare variation_theme and variation_attributes across the children. A child whose theme differs from its siblings, or a child with no parent where you expected one, is a family Amazon has split or a listing that has come loose from it.

Building a sales-rank history you can trust. sales_rank and display_group_rank are today's headline ranks and nothing more; there is no history in the file. Keeping the daily snapshot and stacking sales_rank by asin over time is how you get a rank trend, and sales_rank_title tells you which node the rank is measured in so a node change does not read as a rank collapse.

Checking where Amazon actually filed your product. classification_path is the full browse breadcrumb Amazon places the ASIN under, root to leaf. Compare it against where you meant the product to sit, and compare the spine's classification against the summary's browse_classification when the two disagree.

Feeding dimensions into fee and shipping estimates. package_height, package_length, package_width and package_weight, each with its unit column, are the packaged measurements Amazon holds. Check the item_* scope as well, and treat an all-null dimensions row as "Amazon has none" rather than a missing join.

Image QA across the catalog. Count distinct variant values per asin in the images table to find ASINs with no MAIN image or with fewer secondary slots filled than their siblings, and pick one rendition per variant by height and width before you do so.

Reconciling identifiers with your own systems. upc, ean, gtin and isbn are what Amazon holds against the ASIN. Split the comma-joined values before matching them to an ERP.

Vendor category roll-ups. For a vendor account, product_group, product_category, product_subcategory and replenishment_category give Amazon's own retail hierarchy, which is what Vendor Central reporting is usually cut by.

It is a snapshot, not a history. Ranks move daily, titles and images change, and the record mutates in place. The rows carry no date range, only a snapshot date. If you did not keep yesterday's pull, yesterday's rank is gone.

Only the headline rank is kept. Rank lists arrived with at most one entry per family on every validated row, and only the first is kept. If Amazon returns a second rank in a family, it is not in the file.

Coverage is only the ASINs the call names. The report asks about the ASINs your account lists, because that is the list supplied to it. An ASIN missing from that list is absent from the file, and competitors' ASINs are not in it at all.

vendor_details is access-gated, not sparse. For a seller account the table is header-only, and requesting the section fails the call outright. Do not read an empty vendor details table as missing data.

Dimensions come in two scopes with units beside them. package_ was present on 40 of 60 validated seller items and item_ on 23; 20 of 60 had no dimensions at all and land as an all-null row. The unit columns are not normalised, so never compare or sum measurements without converting on the unit column first.

Images have several rows per variant. Amazon serves several sizes of each image, so counting rows in the images table overstates the number of images. Pick a size by height and width first.

Identifiers are comma-joined. A cell in upc, ean, gtin or isbn can hold more than one value.

Rows are per marketplace. Every table carries reported_marketplace_id, and a pull covering several marketplaces — one call each — produces one row per marketplace for the same ASIN. Join the companion tables to the spine on both columns, or an image list will multiply.

Attributes follow the product type. The keys in attribute_name are whatever the ASIN's product_type defines, so the set differs from one ASIN to the next; there is no fixed column per attribute.