This is the account-level Subscribe & Save report: how the program is doing for you as a whole, in one marketplace, with no ASIN or SKU anywhere in the file. The per-offer version of the same measures is a different operation (listOfferMetrics) and a different page; this one carries the half of the picture that is not a sum over offers.

Each row is one interval for one marketplace. On the operating measures — active_subscriptions, shipped_subscription_units, total_subscriptions_revenue, lost_revenue_due_to_oos, not_delivered_due_to_oos, revenue_penetration and the two coupon columns — the interval is the day you asked for, and those are the rows that behave like a daily table. The rest of the columns are cohort measures, and Amazon returns each of them on its own row over its own trailing window rather than at the day grain you requested: subscriber_retention_for_30_days and _90_days; the seven life_time_value columns, split by customer segment (non-subscriber, lost, growing, established) and by whether the money came from one-time purchases (_otp) or subscription deliveries (_sns); and the eight seller-funding columns, which break revenue_penetration and signup conversion out by how much of the discount you fund (0%, 5%, 10%, 5%-plus). time_interval_start_date and time_interval_end_date are what tell the two kinds of row apart.

Those windows are not all the same length. Amazon dates the seller-funding bands, signup conversion, the three revenue_from_* lifecycle columns and the subscriber/non-subscriber averages over the trailing 12 months for a seller, and lifetime value over the trailing 24 — its own example response answers a single request with a 12-month first row and a second row, carrying only the seven life_time_value columns, over a 24-month interval. grain on this page reads day because that is the closest single term for the operating measures; it is not a description of the whole response, and reading the file as one row per day will lose the rest.

Two comparison pairs sit in the middle: subscriber_average_revenue against non_subscriber_average_revenue, and subscriber_average_reorders against non_subscriber_average_reorders. Amazon dates all four over the trailing 12 months for a seller — six months for vendors on the revenue pair — so they do not move with the interval you asked for either. Three revenue_from_* columns split subscription revenue by where the subscription is in its life — multiple deliveries, active after one, cancelled after one. Amazon states all three over the trailing 12 months whatever interval you asked for, so they are not a split of the total_subscriptions_revenue sitting on the same row. The 12-month window is Amazon's own; whether the three sum to that 12-month subscription total is a different question, and one Amazon does not answer — check it on your own file.

Every money column is in currency_code, which follows the marketplace and is never converted.

Through the Selling Partner API, this comes from the Replenishment API (version 2022-11-07), operation getSellingPartnerMetrics. It is a synchronous endpoint, not a report type: there is no createReport and nothing to poll. You POST a JSON body naming the marketplace, the interval and PERFORMANCE metrics, and the answer comes back in the same call, unpaginated. Because the client has to be built against the marketplace being requested — that is what selects the regional endpoint — it is one call per marketplace: an account selling in several has to make the request once for each.

The body may narrow the request to a list of asins or skus, or name neither and stay account-wide, which is what this page describes. Here is the trap: the response carries no ASIN or SKU whether or not you filtered. A filtered response is shaped exactly like an account-wide one, so a pipeline that lands both on the same day will overwrite the account total with a partial one and have no way to tell afterwards. If you filter, record the filter yourself.

Two things this report will not do. It only answers PERFORMANCE metrics — forecast measures are a separate request, and a table mixing actuals and forecasts under a flag is how someone ends up summing both. And it does not replace the old flat files by name: Amazon removed GET_FBA_SNS_PERFORMANCE_DATA and GET_FBA_SNS_FORECAST_DATA from the Reports API on 11 December 2025 and named this API the replacement, so requests for those report types now end cancelled or return a header and nothing else.

In Seller Central, the Subscribe & Save page is where you manage subscription products and discounts and review the program's metrics: hover over Growth in the main menu, click Explore Programs, then Increase conversion, and choose the Subscribe & Save card. The column set on this page is the API's, and that page does not export these rows in this shape.

Amazon publishes no refresh statement for this endpoint. The response covers whatever interval was requested, and recent days are restated after the fact, so a day already loaded can still change.

Knowing how much of the business is on subscription. revenue_penetration is the one number that says whether Subscribe & Save is a rounding error or a channel. Trend it with active_subscriptions and shipped_subscription_units and you can see whether the base is growing or just churning at a constant size.

Putting a price on stock-outs. lost_revenue_due_to_oos and not_delivered_due_to_oos show what running out cost the subscription base specifically — deliveries Amazon could not make and the revenue that went with them. A subscription skipped for stock is a subscription at risk of cancelling, so this is the argument for protecting inventory on subscribed ASINs before anything else.

Choosing a funding tier. The eight seller-funding columns are the only place Amazon tells you what funding buys. If signup_conversion_for_10_percent_seller_funding is barely above _5_percent_ and revenue_penetration moves the same way, the extra five points are margin given away.

Measuring whether subscribers stick. subscriber_retention_for_30_days and _90_days, read beside the three revenue_from_* lifecycle columns, separate a base that reorders from one that signs up, takes the first-order discount and cancels. revenue_from_cancelled_subscriptions_after_single_delivery beside a high share_of_coupon_subscriptions is the classic shape of a coupon-driven base.

Making the case for subscribers over one-time buyers. The subscriber_average_ versus non_subscriber_average_ pairs, and the seven life_time_value columns, give you the same customer valued as a subscriber and as a one-time purchaser — the number to put against the discount you fund.

Most of the interesting columns are not daily. Retention, lifetime value and the seller-funding bands each come on their own row over their own trailing window, whatever grain you asked for. Such a row cannot be partitioned by day, so in a day-partitioned table those columns are null on every day row; the values exist only in the raw JSON response. If you want them in a table, that table has to be keyed by the interval, not by its start date.

A filtered pull is indistinguishable from an unfiltered one. The response has no ASIN or SKU column even when the request named them. Land a filtered response on a day that already holds the account-wide one and the account-wide numbers are gone; batch several filtered requests onto one day and you have several mutually indistinguishable aggregates. Re-running the day unfiltered is what restores it.

Recent days get restated. Amazon revises recent days late enough that re-requesting the trailing 30 days is the only way to keep a table honest. A pipeline that writes each day once will drift.

One marketplace per call, one currency per row. A multi-marketplace account produces several files, each in its own currency_code. Summing total_subscriptions_revenue across them without grouping on the currency adds euros to dollars.

Two metric groups may be US-only. The release note that introduced the lifetime-value and signup-conversion metrics on 22 December 2025 says they are only supported in the Amazon US store, while the operation's own MarketplaceId schema lists all nine seller marketplaces with no such carve-out and the field schema does not repeat the restriction. Amazon has not reconciled the two, so treat the seven life_time_value columns and the four signup_conversion_* columns as US figures until a non-US pull shows otherwise; a response from another marketplace is what settles whether they come back null there.

Nothing here is per ASIN. For the same measures by offer, use listOfferMetrics. For the offer's configuration — eligibility, price, who funds which discount, the health of upcoming deliveries — use listOffers. This report will not tell you which product is losing subscribers.

No forecasts. This report carries only PERFORMANCE metrics. Forecasts are a separate request — timePeriodType: FORECAST, sellers only — and it answers with just two measures, TOTAL_SUBSCRIPTIONS_REVENUE and SHIPPED_SUBSCRIPTION_UNITS, over the next 30, 60 or 90 days. Every other measure in this API is documented as PERFORMANCE-only, so no forecast figure can arrive in the response this report is built from.

The four funding bands are not one set. Amazon's reference marks the 5% and 10% bands as applicable to sellers only and the 5_plus_percent band — 5% and above — as applicable to vendors only. A seller's split is therefore 0%, 5% and 10% — the reference's own example response returns exactly those three and no 5%-plus — and the two 5_plus columns still arrive in a seller's response because the same schema serves both party types. Whether they simply arrive null on a seller pull is not something Amazon states, so confirm it on your own file before reading anything into them. Either way, adding all four together mixes two different splits of the same base.

Not the AWD replenishment report. The Amazon Warehousing and Distribution "replenishment" orders report describes stock moving from AWD into FBA and shares nothing with this but the word.