One row is one merchant SKU in one country, as of the moment you pulled the file. The row puts three things side by side: what you are holding, how fast it has been selling, and what Amazon suggests you do about it.

The identity columns come first — country, merchant_sku, fnsku, asin, condition, and the supplier and supplier_part_no fields the file carries alongside them. Then the demand side, sales_last_30_days and units_sold_last_30_days, both trailing 30-day windows rather than figures for any particular date.

The unit counts are the bulk of the file. total_units sits above a breakdown by state — available, inbound, fc_transfer, fc_processing, customer_order and unfulfillable — and then three columns for inbound shipments by stage: working, shipped and receiving.

Cover is expressed twice, and the pair is the point: total_days_of_supply_including_units_from_open_shipments counts units in open inbound shipments, while days_of_supply_at_amazon_fulfillment_network counts only what is already in Amazon's network. Both arrive typed as strings.

Amazon's own output is the last group: alert, recommended_replenishment_qty, recommended_ship_date and recommended_action. These carry Amazon's suggestion for the SKU. This page documents what the columns hold, not how Amazon computes them — neither the method behind the quantity nor the set of values alert and recommended_action can take is published.

Two of those columns are not present everywhere. The EU-5 file omits recommended_action, and an MX file omits both recommended_action and unit_storage_size — 30 columns for US, 29 for EU, 28 for MX. A typed copy that holds one schema across marketplaces fills the missing ones with nulls, so an empty column means "this marketplace does not publish it", not "nothing to recommend".

Through the Selling Partner API it is a Reports API request for report type GET_RESTOCK_INVENTORY_RECOMMENDATIONS_REPORT. You submit the request with the marketplace you want, poll it until Amazon returns a document ID, then download the document, which is TSV. There is no date range to supply: the report has no data start or end time, because it describes the present rather than a period.

Requests are made per marketplace, and the supported set is narrow — North America, the EU 5 and Japan. Asking for any marketplace outside it is not an empty file but a guaranteed fatal request, so a fan-out across every marketplace an account sells in will fail on the ones Amazon does not publish. Credentials are endpoint-scoped in any case, so one credential cannot span two regions.

In Seller Central, Amazon lists Restock Inventory among the tools for managing FBA inventory — it is the tool for keeping "inventory at healthy levels", with recommendations "based on your sales history, along with demand and seasonality forecasts" — and documents the FBA inventory area as Inventory → FBA Inventory in the main menu. Whether that page offers the same file as a download is written down only in Seller Central's login-gated help, so the API above is the route this page can stand behind.

The trap that catches people is the EU file. One EU-5 request returns the whole region — a single file of DE, GB, FR, ES and IT rows together, 517,705 rows in one measured file — so five per-marketplace requests each return the same region-wide file, and any per-marketplace label you stamp on the download is wrong for four fifths of its rows. NA does not behave this way: a US request returns US rows only, and an MX request against an account with real MX volume returned 3,941 MX-only rows. Read the country from the in-file country column, never from the request you made.

Ranking what to ship next. recommended_replenishment_qty and recommended_ship_date give you Amazon's suggestion per SKU in one file, which is the practical starting point for a purchase-order cycle — sorted by days_of_supply_at_amazon_fulfillment_network ascending, it is a shipping queue. Treat the quantity as Amazon's opinion rather than a computed reorder point: nothing published tells you what went into it.

Separating a stock-out from a stock problem. A SKU with available at zero but healthy inbound, shipped and receiving numbers is waiting on check-in, not on a purchase order. One with zero across all of them needs stock. The two look identical in a sales report and completely different here.

Finding units you own but cannot sell. unfulfillable counts stock sitting in the network that Amazon will not sell, and it is easy to miss because the units are still yours and still somewhere in the totals. Reviewing it by merchant_sku regularly is how removal orders get raised before the stock ages.

Seeing the same SKU's cover country by country. Because the EU file is region-wide, one pull shows a SKU's available and days-of-supply figures for DE, GB, FR, ES and IT next to each other — useful for spotting that the cover problem is one marketplace rather than the product.

Reconciling supplier lead time against Amazon's date. supplier, supplier_part_no and recommended_ship_date in one row let you check whether Amazon's suggested ship date is even reachable given who makes the product and how long they take.

The EU file is region-wide, and a per-marketplace label on it is wrong. Five requests return five near-identical copies of the same DE/GB/FR/ES/IT file. Anything that trusts the requested marketplace instead of the country column will attribute four fifths of the rows to the wrong country. Deduplicating on merchant_sku alone collapses genuinely different country rows.

The file has no date column. Nothing inside it records when the snapshot was taken; the only date present is recommended_ship_date, which is a suggestion, not a timestamp. Stamp the pull time yourself, or two snapshots become indistinguishable.

Money is not converted, and one file can mix currencies. price and sales_last_30_days carry the row's currency_code. Summing either across a region-wide EU file adds euros to pounds.

Columns exist that the marketplace never fills. recommended_action is absent from EU and MX files and unit_storage_size from MX files; in the typed copy both come back as all-null columns. Code that tests "is this column empty" to decide whether a SKU needs action will read "no action" for an entire marketplace.

The days-of-supply columns are text. Both are typed as strings, so sorting them lexicographically puts 100 before 9, and arithmetic on them needs a parse first.

The recommendations are Amazon's, and undocumented here. The quantity, the date, the alert and the action are values Amazon publishes. What is established is that the columns exist and where they go missing — not how the numbers are produced, what the alert strings say, or what a suggestion implies about your account.

Trailing 30 days is not the same window as anything else. sales_last_30_days and units_sold_last_30_days are a rolling window ending at the snapshot, which will not tie out to a calendar month in a sales report.