A replenishment order is a move of your own stock out of Amazon Warehousing and Distribution (AWD) and into FBA. This is the flow behind the AWD inventory position: listInventory tells you what is standing in AWD, and this tells you what left it, when, and whether it got there.

One pull answers four row grains at once, and the field reference below is grouped by the table each column lands in, so a repeated column such as order_id is listed once under every table it appears in and described for the table it sits in:

- The orders — order_id, status, created_at, updated_at, confirmed_on. One row per replenishment order. This is the headline table, and order is the grain this page is filed under; the other three are described here rather than given grains of their own. - The products — order_id, kind, sku, quantity. One row per SKU on an order. - The shipments — order_id, shipment_id, shipment_status, created_at, updated_at. One row per outbound shipment the order produced. - The ineligibility reasons — order_id, sku, failure_code, failure_reason. One row per SKU AWD refused to move.

order_id is the join key across all four, and the only column that appears in every one. The order's own status runs over CREATED, VALIDATING, ELIGIBLE, INELIGIBLE, CONFIRMED, EXECUTING, INVENTORY_OUTBOUND, SUCCESS and FAILURE; shipment_status is a separate lifecycle on a separate table and does not take the same values. Amazon documents the outbound shipment set as CREATED, IN_TRANSIT, DELIVERED, RECEIVING, RECEIVED, CLOSED, CANCELLED and FAILED, with CLOSED, CANCELLED and FAILED each described as a final state.

Through the Selling Partner API there is no report to create. AWD has no report type and no createReport/getReport flow at all — the data exists only behind the synchronous listReplenishmentOrders endpoint, which answers live and paginated. Calling it means filtering on updatedAt over a rolling window, draining every page in one pass, and rendering the four grains out of the combined JSON document.

Three details catch people, all of them places the endpoint differs from the prose around it:

- The response collection is orders, not replenishmentOrders. - The order's status field is status. Inbound orders call the same concept orderStatus, so a client written for inbound and aimed at replenishment silently reads nothing. - Pagination is an opaque cursor followed until it comes back null, and a cursor that repeats itself is a real failure mode — the loop has to guard against one rather than trust the endpoint to terminate.

python-amazon-sp-api does not wrap this endpoint, so the client is yours to write.

All of this presupposes enrolment in AWD. Amazon's own getting-started path is to log in to Seller Central, review AWD's product requirements there, and then create and send shipments to AWD; for an FBA seller there is no fee to enrol, and a Professional selling account is recommended rather than required.

Amazon's account of the console side is thin. Seller Central's Amazon Warehousing and Distribution page is where you "create and track shipments, view and move your AWD inventory, and track replenishments to the Amazon fulfillment network", and the AWD API guide warns that interoperability between the API and Seller Central is currently limited. Neither names a menu path, an export or a console report for replenishment orders, so there is no console route to this data that Amazon documents.

Main table

products

shipments

ineligible

Computing the auto-replenishment ratio. The share of a SKU's FBA replenishment that came through AWD over the trailing 90 days is what decides whether Amazon waives its low-inventory-level fee and its 181-365 day aged-inventory surcharge. Amazon exposes no trend for that anywhere — grouping the products rows by sku over the window is how you get one.

Explaining an AWD position that will not move. When stock sits in AWD and nothing reaches FBA, the ineligibility grain names it directly: failure_code and failure_reason per sku, per order. That is the difference between "the order was never placed" and "AWD refused this SKU four times".

Finding orders that have stalled. Everything that has not reached SUCCESS or FAILURE is still open. Pair status with updated_at and an order that has sat in the same state for a fortnight is visible without opening the console.

Tying outbound shipments back to the order that created them. The shipments grain joins on order_id, so a replenishment that arrived in three shipments reconciles against the one order and the quantity it covered.

Seeing what is in flight when FBA looks thin. An order that is confirmed but has not reached SUCCESS or FAILURE is stock already committed out of AWD, which is the number a restock decision needs and the one an FBA inventory snapshot cannot show.

Duplicates are the design, not an anomaly. Orders stay open for weeks and are re-emitted on every run that touches them, so the same order appears many times across pulls. Dedupe on (order_id, updated_at) before counting anything.

There is no data date on the record. Each pull is filed by its ingest date, and none of the four tables is day-partitioned — partitioning on an order's own dates would scatter one run's duplicates across historical partitions. A count over a date range therefore counts pull copies, not orders, unless you dedupe first.

This is not the Replenishment API. That one is Subscribe and Save, and shares nothing with this but the word. Reports built from the wrong one look plausible and answer a different question entirely.

The four grains do not sum to each other. Products rows are not orders, shipments rows are not orders, and an order appears in the ineligibility grain once per refused SKU. Counting rows in a flattened join overstates all three.

created_at and updated_at exist on two of the grains — the order and the shipment — with different meanings and different clocks, under the same two names. A join that does not disambiguate them quietly picks one and reads as if it were the other.

An untouched order is absent, not closed. The window filters on updatedAt, so an order that has not changed inside it simply does not appear in that pull even though it is still open. An order's history is assembled across runs, never read out of a single one.