One row is one Subscribe & Save offer on one day. The offer is identified by asin and sku (vendors get no SKU, so on their rows asin alone is the identity), and the day is bounded by time_interval_start_date and time_interval_end_date, which on this endpoint always enclose a single day because Amazon will only answer an interval of exactly one aggregation unit.

The columns fall into four groups. Descriptive columns — brand_name, product_group, fulfillment_channel_type, currency_code — say what the offer is. Performance columns say what happened to it that day: active_subscriptions (a standing count, not an event count), shipped_subscription_units and total_subscriptions_revenue (both flows that add across days), and the two out-of-stock columns, lost_revenue_due_to_oos and not_delivered_due_to_oos. Rate columns — revenue_penetration, coupons_revenue_penetration, share_of_coupon_subscriptions — say how much of the offer's business runs through the program and through coupons.

The fourth group is six forecast columns, next_30_day_…, next_60_day_… and next_90_day_… for both units and revenue. The API declares them, so they are in the schema, but a PERFORMANCE pull — the only kind this report makes — can never carry a value in them. Amazon's reference marks only TOTAL_SUBSCRIPTIONS_REVENUE and SHIPPED_SUBSCRIPTION_UNITS as applying to both timePeriodType values; every other metric, these six included, is PERFORMANCE-only, and a forecast is a separate FORECAST request covering the next 30, 60 and 90 days. So these are always null here — not a gap in the data, but the shape of the request.

Money is decimal so sums reconcile; counts are int64; rates are float64. All three rate columns are percentages on a 0–100 scale in Amazon's own schema, and so is not_delivered_due_to_oos: it is the percentage of items that went unshipped out of total shipped units because the offer was out of stock, a share rather than a count of missed deliveries.

There is no report type for this data. It comes from the Selling Partner API's Replenishment API (v2022-11-07), Amazon's programmatic view of Subscribe & Save, through the synchronous listOfferMetrics operation: a POST with a JSON body rather than the usual createReport/getReport flow, answering pages of offers directly. You ask for PERFORMANCE metrics, a DAY aggregation frequency, and a time interval, and page through the result with limit and offset.

The trap is the interval. Amazon accepts only an interval covering a single unit of the aggregation frequency, so at the day grain that means one day per request; ask for a week or a month and the call is refused with InvalidInput rather than answered. To build history you issue one request per marketplace per day, and recent days are worth requesting more than once: Subscribe & Save figures are restated late, so a day read once has no second chance at it.

The second trap is the page ceiling. offset is capped at 9000, so one request series returns at most roughly 9,500 rows and then stops silently — nothing tells you rows were dropped. At one row per offer per day that is ample headroom; over a multi-day interval (if Amazon allowed one) it would truncate any seller with more than about 315 offers.

The client has to be built against the marketplace being requested, because that is what selects the regional endpoint. Replenishment is not a US-only API: Amazon documents the supported stores as US, CA, ES, UK, FR, IT, IN, DE and JP for sellers and vendors alike, plus BR, AU, MX, AE and NL for vendors only.

The two Reports API flat files that used to carry this data, GET_FBA_SNS_PERFORMANCE_DATA and GET_FBA_SNS_FORECAST_DATA, were removed by Amazon on 2025-12-11, and Amazon named this API as the replacement. Requests for the old report types end CANCELLED or return header-only files.

Sellers have a console route to the program itself: hover Growth in the Seller Central main menu, click Explore Programs, then Increase conversion, and pick the Subscribe & Save card. Amazon says that tool's Dashboard tab shows Subscribe & Save performance and offers a performance report to download, but it does not publish that download's columns, so do not assume its columns are the ones here.

Finding which offers your Subscribe & Save revenue actually rests on. Rank offers by total_subscriptions_revenue and active_subscriptions over a month of daily rows. A handful of ASINs usually carry most of the recurring revenue, and those are the ones whose stock and price you protect first.

Putting a dollar figure on stock-outs. lost_revenue_due_to_oos is Amazon's own estimate of the subscription revenue that did not ship because the offer had no stock, and a subscription delivery that fails is a subscriber who may cancel. Summed by asin across the fortnight it makes the case for a restock far better than a units-on-hand number does.

Measuring how deep the program has reached into an ASIN. revenue_penetration shows how much of an offer's sales already run on subscription. A high-velocity consumable with low penetration is where a Subscribe & Save discount or coupon has room to move demand; one already at high penetration is where a discount mostly gives margin away.

Judging whether coupons are buying subscriptions or just discounting them. share_of_coupon_subscriptions beside coupons_revenue_penetration tells you what fraction of the subscriber base arrived on a coupon and how much revenue that slice carries.

Brand- and category-level roll-ups. brand_name repeats on every offer, so grouping on it gives Subscribe & Save totals for a brand without a separate catalogue join. product_group does the same for a category, but only where it is populated: Amazon documents it as supported for vendors and not for sellers, so check it on your own rows before building a category roll-up on it. Either way, bear in mind the standing-versus-flow distinction below.

The forecast columns are empty. All six next_30/60/90_day_… columns come back with no value on a PERFORMANCE pull, which is the only pull made. Any dashboard built on them will show nulls, not zeros. A FORECAST pull would be a separate report and table, deliberately not mixed into this one under a flag, because a table holding both forecast and actuals is how a consumer ends up summing both.

One day per request, no exceptions. A multi-day interval is refused with InvalidInput. Anything that assumes it can pull a month in one call will fail on the first request.

Pagination truncates silently. The offset ceiling of 9000 caps a request series at roughly 9,500 rows. Past it the result simply ends; there is no error and no flag on the file.

Recent days get restated, late. Amazon revises Subscribe & Save figures well after the day, and publishes no statement of when a day settles. A day pulled once and never revisited will drift away from what Amazon later reports.

active_subscriptions is a standing count. It is the subscriptions live on that day, not an event. Summing it over a month does not give monthly subscriptions; it gives a number that means nothing. Average it, or take the latest day.

sku is null on vendor rows. The endpoint serves sellers and vendors both, and vendor rows have no SKU. Joins keyed on sku will drop every vendor row.

Account-level Subscribe & Save measures are not here. Subscriber retention, lifetime value by customer segment, and revenue penetration and signup conversion by seller-funding band come from a different operation, getSellingPartnerMetrics, and cannot be derived from these per-offer rows. They are also awkward to store at a day grain, because Amazon states each over its own trailing window rather than over the day that was requested.

Money is not converted. Every money column is in currency_code. Sum across marketplaces only after grouping on it.

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.