How to Monitor Amazon Prices and Reviews at Scale

Amazon doesn't publish a price-history API. There's no endpoint that tells you what a product cost last week, or whether a competitor just ran a flash discount. All you can ever get is what the page shows right now — a single frame, not a chart.

That's fine. Monitoring isn't something Amazon needs to hand you as a service. It's something you build yourself, out of the same primitive repeated on a schedule: pull the current price and detail page, pull the current reviews, store the row, compare it to the last one you stored. The part worth getting right is the pull itself — reliable, structured, not something that quietly breaks when Amazon redesigns a product page.

If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.

What makes Amazon product data useful for monitoring?

A handful of fields turn a single scrape into a signal, once you're watching them run over run:

• Price and list price. The gap between the two is the discount, and whether that gap is currently open (onDeal) is more useful than either number alone.
• Rating and ratings count. A rating holding steady while the count climbs fast is a product gaining real traction, not just visibility.
• Best Sellers Rank. BSR moves faster than the rating does — it's the earliest signal that a listing's demand is shifting, in either direction.
• Availability and buy-box seller. Who's actually fulfilling the order changes week to week for competitive listings, and it's often the first thing to move before a price does.

Any one of these on its own is a fact. Watched across a series of pulls, they're a trend.

Why doesn't scraping Amazon yourself hold up at scale?

The same failure modes as any high-traffic marketplace, just faster. Amazon changes product-page markup often enough that a hand-rolled parser breaks on a schedule you don't control, and you find out when a run comes back with empty prices, not when it happens. Running this from a handful of IPs gets you rate-limited or blocked outright once volume climbs past a handful of ASINs a day. And review pages paginate behind their own mechanics, so pulling a full review history means handling that pagination correctly for every product, every time, across ten different regional marketplaces if you sell internationally.

None of this is a one-time build cost. It's upkeep on infrastructure that isn't your product, and it stays broken the longest exactly when a page layout changes without warning.

How do you pull price and review data for a product?

Mindcase splits this into two calls: current product detail, and current reviews. Same ASIN, two different endpoints, because they're refreshed on different rhythms — price moves by the hour, reviews accumulate by the day.

How do you get the current price and detail page?

curl -X POST "https://api.mindcase.co/v1/data/amazon/products/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "urls": ["https://www.amazon.com/dp/B0CHX3QBCH"]
  }
}'

# $0.0015 per product

Amazon Products API takes an array of URLs or bare ASINs, so pulling twenty products for a category watch-list is one call, not twenty. It returns 36 fields — price, list price, discount, rating, ratings count, Best Sellers Rank, availability, seller, and the full product detail (features, images, variants) alongside them. One thing it won't do: pass it a category or search-results page URL and it returns nothing useful — that's what the keywords parameter is for instead, which runs a real Amazon search and returns full detail for every result.

How do you get its reviews?

curl -X POST "https://api.mindcase.co/v1/data/amazon/reviews/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "urls": "https://www.amazon.com/dp/B0CHX3QBCH",
    "maxResults": 100
  }
}'

# $0.0005 per review

Amazon Reviews API takes one product URL or ASIN per call — unlike Products, it doesn't batch multiple ASINs into a single request, so a twenty-product watch-list means twenty review calls, one per product. maxResults tops out at 100: that's Amazon's own per-product cap, not a Mindcase limit. Each row returns 29 fields — rating, review text, verified-purchase status, helpful votes, and the product's own running star breakdown (fiveStar through oneStar) alongside it, so you get the distribution without a separate call.

How do you turn a snapshot into monitoring?

Every call above returns one frame: the product as it looks right now. Monitoring is what you get from running that same call on a schedule and keeping what changed.

The mechanics are simple on purpose. Store each pull with a timestamp — even a flat table with asin, price, rating, bsr, pulled_at is enough. On the next run, compare the new row to the last one for that ASIN: a price that dropped is a discount starting, a BSR that jumped is demand shifting, a ratings count that barely moved despite steady sales is worth a second look. None of that comparison logic lives in the API — it can't, since Amazon itself doesn't expose history, only the present moment. The API's job is making each individual pull cheap and reliable enough that running it daily, or hourly for a short list of competitors, is a rounding error rather than a project.

What can't you get from Mindcase?

Two cases.

A full price history before you started pulling. Nobody has this, including Amazon — every price-tracking tool you've seen a chart from built that chart the same way described above, one snapshot at a time, starting from whenever they turned monitoring on.

More than 100 reviews for a single product in one call. That cap is set by Amazon's own review pagination, not by Mindcase. If you need a product's full review history beyond the most recent 100, that requires Amazon's own seller-side tools — a public-data API reads what a shopper sees on the page, and a shopper never sees more than that either.

Which endpoint should you use for which job?

FAQ