The sales prediction endpoint returns fields named estDailySales and estMonthSales.
est is estimated. The API admits at the field-name level that this is a derived number. That is not a disclaimer, it is information that should change how you use it: the marketplace never publishes real unit sales for any product, so "2,965 units a month" in any tool, any plugin, any report is calculated rather than looked up.
Worth establishing first: how it is calculated, and what that lets you conclude.
The BSR endpoint exposes the whole model
Of the three sales-related endpoints, the clearest one is BSR sales prediction, at POST /v1/amazon/sales/prediction/bsr.
Its inputs are marketplace, bsr and categoryId.
Note what is missing: there is no ASIN. You never tell it which product. Tell it "US marketplace, this category, rank 1024" and it returns estDailySales and estMonthSales.
Which means the model is a curve: given a category, rank maps to sales. What the product is, what it costs, how good the listing copy is — none of that enters the calculation.
Once that lands, several things explain themselves:
- Why the same ASIN shows different monthly sales in different tools — different curves, same rank
- Why categories are not comparable — each category is its own curve, and rank 1,000 in Toys is not rank 1,000 in Automotive
- Why a rank swing moves the sales estimate so much — rank is the only input
What each of the three endpoints is for
| BSR sales prediction | ASIN sales prediction | ASIN sales trend | |
|---|---|---|---|
| Path | /v1/amazon/sales/prediction/bsr | /v1/amazon/sales/prediction/asin | /v1/amazon/asin/sales-trend |
| Input | bsr + categoryId + marketplace | asin | asin + marketplace |
| Returns | estDailySales, estMonthSales, itemList | asinDetail plus dailyItemList, monthItemList | An asin object plus salesTrendPoints |
| Use it for | Turning a rank into an order of magnitude, bulk screening | Daily and monthly series for one product | Monthly series, split parent versus child |
Choosing between them is simple: rank only, use the first; an ASIN and you want a time series, use the second; you need parent and child separated, use the third.
ASIN sales prediction endpointTakes an ASIN, returns product detail plus daily and monthly sales series, with full request and response field tablesA detail: the ASIN endpoint drops the est prefix
The BSR endpoint returns estDailySales. In the ASIN endpoint, the corresponding item inside dailyItemList is just sales, and so is the one in monthItemList.
The name changed; the nature of the number did not. It is still derived. There is direct evidence in the payload: every row of dailyItemList carries both bsr and sales — the input and the output sitting in the same row.
So in your own tables, mark it with a column rather than relying on field names. Which numbers are facts and which are derived should exist explicitly in your data model:
| Field | Nature | Note |
|---|---|---|
price, averagePrice | Fact | Public on the page, quotable directly |
bsr | Fact | The rank the marketplace publishes |
ratings, rating | Fact | Rating count and rating value |
sales, estDailySales, estMonthSales | Derived | Converted from BSR |
amount, parentSalesRevenue, childSalesRevenue | Derived | Derived units × price, so two layers of error |
That last row deserves its own look. Revenue is a derived unit count multiplied by a price, and the errors compound. Fine if you only need an order of magnitude; if you are building a margin model on it, you are stacking an assumption on top of two estimates.
The most common comparison error: parent versus child
Inside salesTrendPoints on the sales trend endpoint, four fields sit together:
parentUnitSales— units for the parentchildUnitSales— units for the childparentSalesRevenue— revenue for the parentchildSalesRevenue— revenue for the child
For an apparel listing with eight colors, parent units are the total across all eight variations; child units are the one color you looked up.
Comparing product A's parent units against product B's child units can be off by several times over, and nothing errors out — you just get a conclusion that looks reasonable. A good share of "this listing outsells ours by miles" in competitor decks comes from exactly this.
The rule is simple: compare like with like. Either all parent or all child, and write which one in the column header.
Three things this data does well
Ranking within a category. Same curve, so relative order is reliable. Answering "which of these twenty competitors is ahead" is what this data is best at.
Judging magnitude. Ten units a day and five hundred units a day are different businesses, and telling them apart needs no precision.
Reading direction. Use dailyItemList or salesTrendPoints over a window — even when the absolute value is off, rising versus falling is usually trustworthy, because the bias moves in one direction along a single curve.
Three things it cannot do
Serve as a promise behind a purchase order. A derived number tells you roughly what that position is worth; it does not tell you what you will sell once you get there.
Compare across categories. Different categories are different curves, so the rank numbers are comparable while the sales estimates are not. Compare rank percentile within a category instead.
Reconcile your own books. Your real unit sales live in Seller Central and SP-API as exact, authorized data. Checking your own books against an estimate is validating a fact with a guess. How to choose an Amazon data API covers that boundary in full.
How to mark it in a spreadsheet
If you are building a research sheet, How to fill in an Amazon product research sheet covers the whole structure. For this one field group, three rules cover it:
- Suffix or color the sales columns so they look different from price and BSR
- Record the fetch time on every row — when the rank moved, the estimate moved
- State parent or child in the header
Do those three and six months later you can still tell which numbers in that sheet are quotable.
Questions
Why do tools disagree on monthly sales? Because the conversion curves differ. Rank is public and consistent; the curve is each vendor's own. Some spread is normal and the magnitude should be close. If even the magnitude disagrees, first check that both are reading the same category level.
How accurate are the estimates? It depends on category and rank band. Top ranks have dense samples and estimate relatively steadily; the long tail is sparse and swings more. Do not expect one blanket error rate.
Can I get a competitor's real unit sales? No. Real unit sales exist only in that seller's own account and authorized data. Anything claiming exact competitor sales is still, underneath, an estimate.
Should I use parent or child? It depends on the question. Use parent to judge whether a style is worth entering; use child to judge whether a color or size is worth stocking. What matters is that the whole sheet is consistent.