Search "best Amazon scraper" and most results are the same shape: a table of tool names, a one-line "best for," and a pricing footnote. What's missing is the part that actually determines whether a pipeline built on top of one holds up — how requests batch, how fresh the data really is, and where Amazon itself draws a hard line no vendor can get past.
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 should you actually evaluate in an Amazon data API?
Four things matter more than the feature list:
- Batching shape. Does one call cover many products, or one product per call? This changes your integration code and your cost math, not just your convenience.
- Freshness. Is a result cached, or read live at request time? A price API that serves a cached page is watching yesterday, not now.
- Marketplace coverage. Amazon runs separate sites per country —
.com,.in,.de,.co.uk, and others each have their own catalog, pricing, and reviews. An API scoped to.comonly half-covers a global brand. - What Amazon itself caps. Review pagination, for one, is limited by Amazon's own site, not by any vendor. A tool that quietly returns fewer rows than promised is hitting that wall, not underperforming.
How do you get product and pricing data?
Amazon Products API takes an array of product URLs
or bare ASINs — batched, not one call per item — plus a keywords mode
that runs a real Amazon search and returns full detail for every result,
ranked.
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",
"https://www.amazon.com/dp/B09B8V1LZ3"
]
}
}'
# $0.0015 per productEach row returns 36 fields — price, list price, discount, onDeal status,
rating, ratings count, Best Sellers Rank, availability, seller, and the
full product detail alongside them. Marketplace is per-URL: a .in link
reads the .in catalog automatically, no separate configuration per
country.
How do you get review data?
This is where the batching shape flips. Amazon Reviews API takes one product per call — no array input — so a twenty-product watch-list means twenty separate review calls, not one batched request. That's a real asymmetry between the two endpoints, not an oversight: prices change by the hour and benefit from batching a whole catalog at once, reviews accumulate by the day and are read one product at a time.
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 reviewEach row returns 29 fields — rating, review text, verified-purchase
status, helpful votes, and the product's own star-count breakdown
(fiveStar through oneStar) alongside every review, so distribution
comes free with the pull.
What caps every Amazon API the same way, regardless of vendor?
Two limits, and neither is a vendor limitation:
100 reviews per product per call. That's Amazon's own pagination depth. Any tool claiming to pull "all reviews" for a high-volume product in one call is either wrong or silently making repeated requests behind the scenes — worth asking which, since it changes your real cost.
No price history. Amazon doesn't publish one, so no API can return one. Every price chart you've seen was built the same way: repeated snapshots, stored and diffed over time, starting from whenever monitoring began. A vendor offering "historical pricing" out of the box is either running their own long-running snapshot pipeline (worth knowing, since that's a real cost they're passing to you) or backfilling with estimates.
What does a real monitoring setup actually cost?
Take a mid-size competitive-intel setup: 50 products tracked for price and detail once daily, plus a review pull for the same 50 products once a week. Products batches, so the daily pull is one call covering all 50 — 50 rows × $0.0015 = $0.075 a day, or about $2.25 over a 30-day month. Reviews don't batch, so the weekly pull is 50 separate calls at up to 100 reviews each; at a typical 100 reviews returned per product, that's 5,000 rows × $0.0005 = $2.50 a week, or roughly $10.75 over a ~4.3-week month. Full setup: about $13/month for daily price monitoring and weekly review tracking across 50 products — and that's the real per-row math, not a subscription tier you'd have to guess whether you'd outgrow.
That's the other reason the batching-shape question from earlier matters beyond convenience: it's exactly what separates a $2.25 line item from one that scaled linearly with API calls instead of rows.
Which endpoint should you use for which job?
| Endpoint | Input | Price | Best for |
|---|---|---|---|
| Amazon Products | Array of URLs/ASINs, or a keyword search | $0.0015 / product | Batched price and detail monitoring across a catalog |
| Amazon Reviews | One product URL/ASIN per call | $0.0005 / review | Review-volume and rating-distribution tracking |
FAQ
No. Marketplace is set per request — a full URL uses its own marketplace automatically, and a bare ASIN uses whichever marketplace parameter you pass. Covering five countries means five separate calls or URL sets, not one multi-region request.
Live on every call. Nothing is cached — each request reads the current state of the page at the moment you query it, the same view a shopper loading that page would see.
Not directly. Category and listing-page URLs aren't supported. Use a keyword search instead, which runs a real Amazon search and returns full product detail for every result, ranked.
Prices and detail pages change by the hour and are cheap to batch across a whole catalog in one call. Reviews accumulate more slowly and are pulled per product, which keeps each review call scoped and predictable rather than one enormous multi-product request.