One row is one inbound shipment on the supplier → AWD leg: stock travelling from wherever it was made or held into an Amazon Warehousing and Distribution facility, before any of it moves on to FBA. Six columns, in three pairs. shipment_id and order_id say which shipment this is and which AWD order it belongs to. shipment_status says where Amazon thinks it has got to. created_at and updated_at say when the record appeared and when it last changed, and external_reference_id is the hook back to your own paperwork.

The report exists because of what the AWD inventory report leaves open at the top. That report says how much stock is on hand and how much is in transit to AWD — but not which shipments that transit is, whether any of them have stalled, or which order they belong to. This is the report that names them.

Only three of the six columns are guaranteed: order_id, shipment_id and shipment_status. The other three come from the same summary and may simply not be there, so treat them as optional rather than as the shape of every row.

What is deliberately not here is the detail underneath a shipment: carrier, tracking number and expected-versus-received quantities are not on the summary, and getting them means calling Amazon's per-shipment detail operation once for every row. That is a different report, and it does not exist yet.

The record carries no data date range — it is a list of shipments as they stand at the moment of the call, not a day's data — and the list operation is filtered on updatedAt over a rolling window. Each file is a snapshot rather than a period: it says where the shipments it names had got to when it was pulled, and the same call an hour later can answer differently. Consumers therefore dedupe on (shipment_id, updated_at) rather than on shipment_id alone.

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 listInboundShipments operation, which answers pages of shipment summaries directly rather than going through the usual createReport/getReport flow.

Pagination is the 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, or the loop never ends and the same page is appended forever. It is the one part of the loop worth getting right before trusting a row count.

The second trap is the rolling updatedAt filter. Ask for shipments updated in the last N days and you get exactly that: a shipment nobody has touched inside the window is absent from the file, even though it is still open. The file is a list of what moved, not an inventory of what exists.

The third is the detail call. Carrier, tracking and expected-versus-received quantities need the per-shipment detail operation, which is one call per row against a 2 requests-per-second limit — a thousand open shipments is over eight minutes of nothing but detail calls.

There is an AWD page inside Seller Central — Amazon points sellers at it to create and track shipments and to move AWD inventory — and the API and the console see each other only partly: a shipment created through the API shows up in Seller Central once it is confirmed, and one created in Seller Central can be read back through listInboundShipments. Amazon also says there are no AWD reports in the API at all and points sellers at Seller Central to download an Inbound Shipment report by hand — but where that page sits in the menu, and what columns that download carries, is not published outside the logged-in help centre.

Telling "not enrolled in AWD" apart from "enrolled with nothing stored". An empty inventory response means either one, and those are very different conversations to have with a seller. Any inbound shipment at all settles it — which is why this report is worth running even for accounts whose AWD inventory comes back empty.

Naming the stock that inventory only counts. The AWD inventory report gives you a quantity in transit. This gives you the shipments that quantity is made of, so "3,400 units inbound" becomes four shipments with ids, statuses and dates you can act on.

Finding shipments that have stalled. A row whose shipment_status has not advanced while updated_at recedes further into the past is the one worth chasing. Amazon documents CLOSED and CANCELLED as the two final states, so "still open" is everything else — CREATED, SHIPPED, IN_TRANSIT, RECEIVING and DELIVERED. Sorting those by updated_at ascending puts the stalled ones at the top of the list.

Tying Amazon's record to your own. external_reference_id is the column that matches a shipment back to a purchase order or a supplier's shipment number, which is what makes a reconciliation between your supply plan and Amazon's view of it possible at all.

Putting shipments beside the order they belong to. order_id joins these rows to the AWD order behind them, so a shipment can be read in the context of what was ordered rather than as a bare id.

Building the history Amazon does not keep. Because each pull carries updated_at, storing every pull gives you a status timeline per shipment — when it shipped, when it started receiving, when it closed — which no single call to the endpoint can answer.

Summaries only. Carrier, tracking number and expected-versus-received quantities are not on this report. Anything that needs them needs the per-shipment detail operation, one call per shipment against a 2 requests-per-second limit.

Three of the six columns are not guaranteed. order_id, shipment_id and shipment_status are the ones the endpoint promises. external_reference_id, created_at and updated_at come from the same summary and may be absent, so code that assumes they are always populated will break on the row where they are not.

The file is not a list of all open shipments. It is filtered on updatedAt over a rolling window, so a shipment that has not changed recently is simply not in it. Treating one file as the complete picture undercounts exactly the shipments that have gone quiet — which are the ones worth looking at.

The same shipment appears in many pulls. There is no data date range on the record, and windows overlap. Dedupe on (shipment_id, updated_at); counting rows across accumulated pulls counts the same shipment once per update it received.

Do not filter on status strings you have not seen. Amazon documents seven statuses — CREATED, SHIPPED, IN_TRANSIT, RECEIVING, DELIVERED, CLOSED and CANCELLED — but a documented value set is not evidence about what one account's file contains. Check a real file before writing a query that hinges on one.

The timestamps are record events. Amazon defines createdAt as when the shipment was created and updatedAt as when it was last updated: both describe the shipment record, and neither is documented as marking a physical milestone such as the day the supplier despatched or the day AWD received. Do not read a despatch or receipt date off either.

This is not the AWD replenishment orders report. That one covers the other leg, AWD out to FBA. A shipment here is stock arriving at AWD; nothing on this page says anything about what leaves it.

It is not an FBA inbound shipment either. The FBA inbound reports cover shipments into Amazon fulfilment centres. AWD is the warehouse in front of them, and the two sets of shipment ids do not overlap.