A row is a SKU's sellable Amazon-fulfilled stock at the moment the report was generated. Six columns, and they divide cleanly: three identifiers - seller_sku, fulfillment_channel_sku and asin - then two condition fields, condition_type and warehouse_condition_code, then a single number, quantity_available. Whether one SKU can occupy more than one row - a row per condition - is not established, and Amazon's reference defines neither condition column, so sum a SKU's rows rather than expecting exactly one.

What the file lacks is the more important half of the description. There is no date column, so a row is true as of the pull and carries no claim about any other moment. There is no country or marketplace column, and that is not an omission Amazon forgot to fix: FBA inventory is pooled, and one unit in a US fulfilment centre is sellable on amazon.com, on amazon.ca through Remote Fulfilment, and on amazon.com.mx. The unit has a location; this report does not carry one. And there is no breakdown of the position - no reserved, no inbound, no unfulfillable. Everything the file says about a SKU is how many of it can be sold now.

That is what separates it from the other FBA inventory reports. If the question is per-marketplace, or needs the reserved, inbound and unfulfillable split, it belongs to the FBA Inventory Planning Data report, which is genuinely marketplace-scoped and says so in its own marketplace column. This report is the flat, whole-account answer to "how many units can I sell right now".

Through the Selling Partner API, it is a Reports API request for report type GET_AFN_INVENTORY_DATA. You create the report, poll it until Amazon hands back a document ID, then download the document, which is TSV. There is no data start or end time to supply, because the report describes the present rather than a period.

The trap is the marketplace parameter, and it is a quiet one: Amazon ignores the marketplace filter here. The behaviour was measured two ways on 2026-08-27 against a seller holding real inventory in both the US and Canada. A US request and a CA request each returned 41,040 rows, 8 units apart out of 255,670 - pull-to-pull drift, not different data. And the quantity is the pooled figure, not the US slice: reconciled against the marketplace-scoped planning report minutes later, AFN's 249,442 units sat 1.2% from US plus CA available (252,535) and 17.4% from US available alone (212,392). Decisively, 48 SKUs stocked in Canada and not in the US were all present, stocked, in the AFN file - which no US-only file could contain.

So the correct way to pull it is once per account, claiming no marketplace at all, and to leave the marketplace null on the stored rows: null is the honest value here rather than a gap. Fanning the request out across every marketplace an account sells in returns the same file N times, and stamping the requested marketplace onto those rows invents a country column the data does not have.

Answering how much you can actually sell right now. quantity_available summed over a SKU's rows is sellable FBA stock, with nothing in it that is reserved, in transit or unfulfillable. That makes it the cleanest input to an available-to-promise figure, and a much smaller thing to reconcile than a planning file.

Reconciling Amazon's SKU list against your own. seller_sku, fulfillment_channel_sku and asin on one row is the mapping most internal systems are missing. SKUs in the file that your ERP does not know, or ASINs carrying stock under a SKU you retired, both show up as soon as the three identifiers sit side by side.

Building the time series Amazon does not hand you. The file has no date, so a snapshot stored on a schedule is the only way sellable stock by SKU over time exists at all. Stamp the pull date on ingest and a month of pulls becomes the cover, sell-through and stock-out history the report itself cannot answer.

Catching the stock-out before support does. A SKU with no sellable units left is out of stock for every marketplace the pool serves at once, not just one - which is exactly the shape of outage that a per-marketplace dashboard reports late. Watch for the SKU vanishing from the file as well as for a zero in quantity_available: whether Amazon writes the zero row or omits the SKU is not established, and comparing today's pull against yesterday's catches it either way.

Splitting stock by condition. condition_type and warehouse_condition_code separate the position into whatever conditions Amazon is holding units under, so new stock is not silently totalled together with used or warehouse-deal units. Amazon lists both columns in its report-type reference and enumerates neither, so confirm the value sets on a real file before writing rules against them.

Deciding which inventory report a question belongs to. A pooled "can I sell it" question is this report. A per-marketplace one, or anything needing the reserved, inbound and unfulfillable breakdown, is the FBA Inventory Planning Data report - and using this file for it produces a number that is wrong by roughly the size of your other marketplaces.

The marketplace filter does nothing, and it fails silently. You get a well-formed file with plausible rows for the marketplace you asked about; it is simply the whole pooled account position. Nothing in the response says so, which is why this is the first thing to know about the report.

Never label these rows with the marketplace you requested. The pooled units have no marketplace, so a marketplace column added from the request is wrong for every row that holds stock outside it. Leave it null.

Never union per-marketplace pulls. Nine requests return nine copies of the same file. Stacking them multiplies the account's inventory by nine, and every row looks legitimate.

Do not compare the total to one marketplace's available quantity. Measured against the planning report, the same account's AFN total was 17.4% above US available alone. A reconciliation that treats the two as the same figure will chase a difference that is just Canada.

There is no date in the file. If the pipeline does not stamp the snapshot date on ingest, the rows are undatable afterwards, and two snapshots concatenated become one indistinguishable pile.

History cannot be assumed. The request takes no date range, and what Amazon documents keeping is the generated report document - 90 days, the default for a report type that names no retention of its own - not the position it described. Ask for the report again and you get today's, because the content is near real-time. Treat a missed pull as data you may not be able to recover.

The position drifts between calls. Two pulls minutes apart differed by 8 units out of 255,670. That is small, but it means an exact tie-out between this file and anything pulled at a different moment is not achievable, and a difference of a few units is not a bug to investigate.

Sellable only. Reserved, inbound and unfulfillable units are not in this file at all, so it undercounts what you own in Amazon's network - deliberately, and by however much is currently in those states.

The raw column headers are not the tidy names on this page. In the TSV Amazon sends hyphenated, inconsistently cased headers - seller-sku next to Warehouse-Condition-code next to Quantity Available. Parsers that match on exact case are the usual casualty; the names in the field reference above are the normalised ones.