One row in the headline table is one SKU's stock position at Amazon Warehousing and Distribution at the moment the endpoint was called. Six columns say where that SKU's units are: total_onhand_quantity for what is standing in the warehouse, total_inbound_quantity for what is still travelling to it, available_distributable_quantity and reserved_distributable_quantity for how much of the position can be sent onward to FBA and how much is spoken for, and replenishment_quantity alongside them.

One pull answers two row grains, and the field reference below is both tables' columns in one list, which is why sku appears twice:

- The per-SKU position — sku, total_onhand_quantity, total_inbound_quantity, available_distributable_quantity, reserved_distributable_quantity, replenishment_quantity. One row per SKU per snapshot. - The expiration buckets — sku, expiration, onhand_quantity. One row per SKU per expiry date, and only for the minority of SKUs that carry dated stock at all.

sku is the join between them. How the quantity columns relate to each other — whether available and reserved partition the on-hand total, whether the buckets sum to it — is not something this page will assert, because the notes behind it do not.

The thing to hold on to is that this is a position, not a period. There is no date column in the file. The row is true as of the call and carries no claim about any other moment, which is what separates it from every report on this site that has a start_date.

There is no report type to request and nothing to poll. The data comes from the Selling Partner API's Amazon Warehousing and Distribution (AWD) API, through the synchronous listInventory operation, which answers pages of inventory directly rather than going through the usual createReport/getReport flow. A complete pull means following the cursor to the end of the list, and the combined JSON carries both grains nested inside the same document — the per-SKU position and the expiration buckets — rather than as separate responses, so they have to be flattened apart to be read as two tables of rows.

Five of the nine columns are conditional on one request parameter. Amazon returns inventoryDetails — the available, reserved and replenishment quantities — and expirationDetails only when the call passes details=SHOW; the parameter defaults to HIDE, which answers inventory summary totals alone. A pull that leaves it out comes back with the SKU and the two totals and nothing else, which is one reason an expiration table can be empty.

The trap is the one that gives the report its character: listInventory has no date dimension and Amazon keeps no history. You cannot ask it for last Tuesday, and no lookback parameter will make it answer one. The time series exists only because someone stored each response, and the endpoint will not backfill, so a gap in your snapshots is a gap nobody can fill later.

Pagination is the second trap. AWD hands back an opaque cursor and you follow it until it comes back null, which means a caller has to guard against a cursor that repeats itself, or the loop never terminates and the same page is appended forever. Amazon also warns that the operation can return empty pages, so an empty page is not the end of the list — only a null nextToken is. It is worth reading that loop before trusting a row count.

There is a console view of the same stock: Amazon says the Amazon Warehousing and Distribution page in Seller Central is where you create and track shipments, view and move your AWD inventory, and track replenishments into the fulfilment network. Whether that page offers an export matching this file, and under what menu it sits, is not something Amazon documents publicly.

Main table

expiration

Knowing how much upstream stock you actually have. FBA inventory reports stop at the fulfilment centre. This is the only view of the buffer standing behind it, so "we have six weeks of cover" is a claim you can only check by reading AWD's on-hand position beside FBA's.

Separating stock that can move from stock that cannot. available_distributable_quantity and reserved_distributable_quantity split the AWD position into what a replenishment can draw on now and what is already spoken for. A healthy on-hand total with almost nothing available is a different problem from an empty warehouse, and only these two columns tell them apart.

Seeing what is still arriving. total_inbound_quantity is the units on their way in. Read it with the on-hand figure before deciding to reorder, or you order against a warehouse that is about to be refilled.

Watching dated stock before it becomes a write-off. For the SKUs that carry them, the expiration rows give a quantity per expiry date — which is the input to selling dated units down in time, and something no aggregate on-hand number can show.

Building the trend Amazon does not keep. Because the endpoint answers only "now", storing each snapshot is what turns this into a series: AWD cover by SKU over time, the day a SKU went to zero, the week reserved quantity started climbing. None of that can be recovered afterwards.

Telling an AWD position apart from AWD activity. This report counts units standing still. The inbound shipments report names the shipments arriving, and the replenishment orders report covers the moves out to FBA. A stock question is this one; a "where did it go" question is one of theirs.

There is no date in the file. Every row is as-of the call. If your 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 backfilled. Amazon keeps none. A month of missing pulls is a month that no amount of API access will recover, which makes this one of the few reports where a broken schedule is permanent data loss rather than a delay.

Most SKUs have no expiration rows. Only a minority of SKUs carry expiration buckets, so an empty expiration table is the normal case. Code that joins the position table to the buckets needs an outer join, or it will silently drop most of the catalogue.

The two grains do not sum to each other. Counting rows across both tables counts neither SKUs nor buckets. Whether a SKU's bucket quantities add up to its total_onhand_quantity is not established here — check it on a real file before reporting one as the other.

An empty response is ambiguous. Nothing comes back for a seller with no AWD stock and nothing comes back for a seller who is not enrolled in AWD either. The inbound shipments report is what tells those two apart.

This is an AWD position, not an FBA one. Units counted here are in the warehouse in front of FBA and do not appear in FBA's inventory reports, so adding the two totals together overstates what is standing in fulfilment centres by exactly the amount that still has to be replenished. Amazon does say that with auto-replenishment left on a product is "considered in stock and buyable" once AWD receives it, so outside FBA is not the same as unsellable.

replenishment_quantity is stock that has already left AWD. Amazon defines it as the quantity in transit from AWD that has not yet been received at FBA, so it is neither standing in the warehouse nor sellable through FBA — a dashboard that adds it to the on-hand total is counting units that are no longer there. Whether it ties out to the AWD replenishment orders report is a separate question this page does not answer.