One row is one Subscribe & Save offer, identified by sku and asin, as it stands at the moment you pull it. The other two Replenishment API reports say what the program did — subscriptions active, units shipped, revenue lost to stock-outs. This one is the state behind those metrics: whether the offer is eligible at all (eligibility, program_type), what it costs (price, price_currency_code), how much inventory backs it (inventory, stock_risk), how many subscriptions it carries (subscriptions), and how it got into the program (enrollment_method, auto_enrollment).

Four percentage columns say who funds which discount. amazon_funded_base_discount_percentage and selling_partner_funded_base_discount_percentage split the base Subscribe & Save discount between Amazon and you; the two _tiered_discount_percentage columns do the same for the tiered, higher rate. The seller-funded pair is the part you control.

Four delivery columns look forward: next_15_days_deliveries, next_30_days_deliveries, next_60_days_deliveries and next_90_days_deliveries. They are nested windows, not buckets — every delivery in the 15-day count is also in the other three — so adding them together counts the near-term deliveries four times.

Each offer also carries a variable-length list of delivery conditions, which is not one schema with the offer row, so it lands in a second table: sku, asin, condition and a next_30_days_deliveries per condition. That is where you see how many of the coming month's deliveries are paused or at risk rather than simply due. Amazon enumerates five conditions: paused on a pricing issue, paused because the offer is not buyable, at low-inventory risk (two variants), and no issues at all.

Money is decimal so sums reconcile; counts are int64; percentages are float64. Amazon keeps no history of any of this, so a time series of price, discount, inventory or subscriptions exists only because it was snapshotted — and a stored copy has to stamp each pull with the day and marketplace it was taken in.

There is no report type for this data and nothing to poll. It comes from the Selling Partner API's Replenishment API (v2022-11-07) through the synchronous listOffers operation: a POST with a JSON body that answers pages of offers directly, rather than the usual createReport/getReport flow. You page through the result with limit and offset. The client has to be built against the marketplace being requested, because that is what selects the regional endpoint, so a multi-marketplace account is one request series per marketplace. Replenishment is available in many marketplaces, not only the US: Amazon's reference names US, CA, ES, UK, FR, IT, IN, DE and JP as the stores supported for sellers, and BR, AU, MX, AE and NL as vendor-only.

The operation is sellers only. Amazon documents it as not supporting vendors, which is why every row here has a SKU where the offer metrics report sometimes does not.

The trap is the page ceiling. offset is capped at 9000, so one request series returns a little over nine thousand offers and then stops silently — no error, no flag, the result simply ends. A catalogue with more Subscribe & Save offers than that cannot be pulled whole through this operation.

The second trap is time. listOffers answers only the present, and Amazon keeps no history of it. If you want to know what an offer's price, discount split or subscription count was last month, the only place that can exist is a snapshot you took last month. History here is something you decide to build, not something that accumulates.

This API family replaced the two Reports API flat files, GET_FBA_SNS_PERFORMANCE_DATA and GET_FBA_SNS_FORECAST_DATA, which Amazon removed on 2025-12-11; those carried performance and forecast figures, and the offer configuration on this page has no flat-file predecessor to fall back on. The offers themselves are visible in the console — Amazon documents reaching the Subscribe & Save page by hovering Growth in the Seller Central main menu, clicking Explore Programs, then Increase conversion, and selecting the Subscribe & Save card, which is where subscription products, discounts, metrics and recommendations are managed — but Amazon documents no export from that page, so the API is the only route to the file.

Main table

deliveries_conditions

Finding out why an offer has no subscribers. Before touching the discount, check eligibility and program_type. An offer that is not eligible cannot be subscribed to at any price, and a row with subscriptions at zero and an ineligible flag is a listing or enrolment problem, not a demand problem.

Catching a stock-out before it skips deliveries. inventory beside next_30_days_deliveries is the plain arithmetic; stock_risk is Amazon's own label for the same thing. An offer whose inventory is below its next month of deliveries is about to miss subscriptions, and the offer metrics report will show the lost revenue only after it has happened.

Seeing what the funding split actually is. The four _discount_percentage columns are the only per-offer record of who pays for the shopper's discount. Grouping offers by selling_partner_funded_base_discount_percentage tells you which tier each SKU is in, and joined to the offer metrics report it is the input to whether the extra points you fund buy anything.

Sizing committed demand. next_90_days_deliveries is, per offer, the deliveries already scheduled for the coming quarter — demand that exists before any advertising. Summed by asin (one window only, never all four) it is a floor for the purchase order.

Separating paused deliveries from stock risk. The delivery conditions table breaks next_30_days_deliveries down by condition. A month with many deliveries paused by subscribers reads very differently from one where the same number are at risk because you have no stock, and the offer row alone does not tell them apart.

Tracking configuration changes over time. Because Amazon keeps no history, a daily snapshot of price, subscriptions and the discount columns is the only way to see a price change land, an auto-enrolment happen, or a subscription base drift down. Two snapshots differ by exactly what changed between them.

There is no history. Amazon states the current configuration and nothing else. A pipeline that starts snapshotting today has no data for yesterday and never will. Anything that assumes it can backfill will find nothing to backfill from.

Nothing refreshes on a schedule. listOffers is answered when it is called, and Amazon publishes no freshness or refresh statement for the operation — neither the reference nor the Replenishment API overview says how current the figures inside the answer are. If you want a time series, something on your side has to call it every day, and that frequency is yours, not the data's: the rows cover no period at all — each one is a position at the instant of the call — which is why this report is a snapshot however often you take it.

The delivery windows nest. next_15_days_deliveries is inside next_30_days_deliveries, which is inside next_60_days_deliveries, which is inside next_90_days_deliveries — Amazon defines each as the projected deliveries in the next 15, 30, 60 or 90 days, all counted forward from now. Sum any one of them across offers; never sum the four together.

Pagination truncates silently. The offset ceiling of 9000 caps a request series at a little over nine thousand rows. Past it the result simply ends, with nothing on the file to say rows were dropped.

Standing counts do not add across days. subscriptions and inventory are positions at the moment of the pull. Summing a month of snapshots gives a number that means nothing; take the latest, or difference two.

Two tables, not one. The delivery conditions are a variable-length list per offer and land in their own table keyed by sku and asin. Reading the offer table alone, you see how many deliveries are due; only the conditions table says how many of them are paused or at risk.

Two label columns have no documented value set. Amazon enumerates program_type, eligibility, enrollment_method, auto_enrollment and condition, and those values are given in the column descriptions above. stock_risk and fulfillment_network_id_type it declares as plain strings with no value list at all, so check a real file before filtering on either. auto_enrollment in particular is a string — OPTED_IN or OPTED_OUT — not a boolean.

Sellers only. Vendors cannot call this operation, and vendor_codes should not be expected to carry anything on the rows this report produces.

Money is not converted. price is in price_currency_code, which follows the marketplace.

This is not the AWD Replenishment Orders report. That report covers inventory moves from Amazon Warehousing and Distribution into FBA and shares nothing with this one but the word.