This is your own listing record for every SKU you sell in a marketplace, as Amazon holds it on the day you ask. It is not a Reports API file: it comes from the Listings Items API, one item resource per SKU, and that resource answers five sections at once, so the file lands as five tables joined on sku. There is no parent table, because the item itself has nothing beyond its SKU.

Summaries is one row per SKU per requested marketplace, strictly one per item on every validated pull. It carries the identity of the listing: asin, product_type, condition_type, status, fn_sku, item_name, created_date, last_updated_date, and the main image as main_image_link with its main_image_height and main_image_width.

Attributes explodes the product-type attribute blob one row per element. Attributes are an open vocabulary — 101 distinct names across one seller's 723 items, each value a list of product-type-specific objects, 26,056 elements in all — so no fixed set of columns can hold them. Each row is attribute_name, the element's attribute_index, the reported_marketplace_id and language_tag most elements carry, the scalar value where the element has one (about two thirds did), and the whole element as canonical JSON in value_json, which is the lossless copy.

Issues is one row per open listing issue, zero to three per validated item: code, message, severity, the affected attribute_names, categories and enforcement_actions (each comma-joined), and exemption_status with exemption_expiry_date. Offers is zero or one row per item with offer_type, price, price_currency_code, audience and audience_display_name. Fulfillment availability is zero or one row per item with fulfillment_channel_code and, on merchant-fulfilled channels only, quantity.

Everything is current state and mutates in place: issues appear and resolve, offers reprice, quantities move. There is no date range on any row, only the snapshot date the pull was made. The sample on this page joins the summaries, offers and fulfillment availability tables on sku into one view; the file itself keeps them apart.

There is no report type for this data in the Reports API or in Data Kiosk. It comes from the Selling Partner API's Listings Items API (v2021-08-01) through the synchronous, paginated searchListingsItems operation. You pass the marketplace and ask for the includedData sections you want — summaries, attributes, issues, offers and fulfillmentAvailability, five of the eight the operation offers — and Amazon answers up to twenty SKUs per page. Each page returns the same item resource as the per-SKU getListingsItem, so one drain of the pages replaces thousands of single calls.

The trap is that rows are stamped with the marketplace that was requested. marketplaceIds is honoured exactly: one credential answered 723 items for the US and 60 for Canada, and every summary in both pulls carried the requested marketplace and nothing else. Amazon's own guide to searching listings covers "single or multiple Amazon stores in the same region" and points at searchListingsItems for them, with the twelve-store cap and the sellers-only restriction it states written against the per-SKU getListingsItem. The payload's own ids are still carried as reported_marketplace_id wherever Amazon writes them, so a response that spanned marketplaces would land visibly rather than mislabelled.

The second trap is in the raw JSON rather than the tables: offer prices arrive as strings ("17.0"), and the currency appears twice, under currency and currencyCode. If you parse the payload yourself, cast the price and pick one currency field; the tables here already do both.

Whether any Seller Central screen offers the same record as a download is not something this page can establish: Amazon's developer documentation for the Listings Items API names no console path, and Seller Central's own help articles sit behind a login.

summaries

attributes

issues

offers

fulfillment_availability

Finding every listing with an open issue, and what Amazon will do about it. Join the issues table to summaries on sku and sort by severity. enforcement_actions says what Amazon has done or will do to the listing, attribute_names says which fields to fix, and message says why. If you snapshot it daily, the set of code values that disappear between two pulls is your list of issues resolved.

Auditing listing content without opening every detail page. item_name and the attributes table hold what Amazon actually has for each SKU, which is not always what you last submitted. Filter attribute_name to the fields you care about, read value where it is filled and value_json where it is not, and compare across SKUs of the same product_type.

Catching price drift. price and price_currency_code are the offer as it stands today. Stacking daily snapshots by sku shows when a price moved, which is the thing to line up against a Buy Box percentage drop in the Sales and Traffic report.

Reconciling merchant-fulfilled stock. quantity on DEFAULT rows is the merchant-fulfilled quantity Amazon is selling against. It is blank on FBA rows by construction, so use it for your own-fulfilled SKUs and an FBA inventory report for the rest.

Mapping SKU to ASIN to FNSKU. The summaries table is the one place sku, asin and fn_sku sit in the same row for every listing in a marketplace, which is the join most warehouse and labelling work needs.

Spotting listings that have gone quiet. last_updated_date beside created_date tells you which listings have not been touched since they were created, and which changed yesterday when nobody meant to change them.

It is a snapshot, not a history. Issues appear and resolve, offers reprice, quantities move, 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 issue list is gone.

quantity is blank on FBA rows, and that is correct. fulfillmentAvailability.quantity only arrives on merchant-fulfilled channels (DEFAULT); FBA channels (AMAZON_NA) answer the channel code alone. A blank is not zero stock.

Attributes have no fixed schema. The keys in attribute_name are whatever the SKU's product_type defines, and every value is a list of objects. Only about two thirds of elements have a scalar value; the rest exist only in value_json. Code that reads value alone drops a third of the data.

Rows are per requested marketplace. Every summary carried the marketplace that was requested, so covering two marketplaces gives two sets of rows for the same SKU. Join the companion tables on sku within one marketplace's pull, or an attribute list will multiply.

Issue lists are comma-joined. attribute_names, categories and enforcement_actions can each hold several values in one cell. The values are identifiers that cannot carry commas, so splitting is safe, but a naive equality filter will miss rows.

exemption_expiry_date has never been seen populated. Every validated exemption was NOT_EXEMPT, which has no date. The column is carried from Amazon's documentation so a suppression deadline is not dropped if one arrives; do not read it as always empty.

B2B offers are not profiled. Every validated offer was B2C, so B2B fields (quantity discount plans) and Japan points are deliberately absent from the offers table. A seller with B2B pricing needs a validated file before those columns can be trusted.

A SKU can have no row in four of the five tables. Offers and fulfillment availability arrived zero-or-one per item and issues zero to three; a missing row is a listing with no offer, no channel entry or no issue, not a failed join.