How to Audit 10,000 Amazon Reviews Across a Product Catalog

Reading reviews one product at a time doesn't scale past a handful of SKUs. If you sell more than a few variants — different sizes, colors, bundles, each with its own ASIN — the reviews that actually matter are scattered across all of them, and no single product page shows you the pattern across the whole line.

Auditing at scale means pulling reviews for every ASIN in a catalog, not just the flagship one. The real constraint that shapes this job: Amazon caps what any tool can retrieve at 100 reviews per product. Auditing 10,000 reviews isn't one big pull — it's roughly 100 pulls, one per product, stitched together.

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 reviewing a whole catalog different from one product?

A single product page tells you what people think of that variant. It doesn't tell you if the 2-star reviews cluster around one SKU's packaging while the rest of the line is fine, or whether a recent batch across every variant mentions the same defect. That pattern only shows up once you've pulled reviews for every ASIN and can compare them side by side — which means treating "reviews" as a dataset you query across products, not a page you read one at a time.

How do you pull reviews for one product?

Start with a single ASIN or product URL. The Amazon Reviews API returns everything Amazon itself shows on that product's review section — text, rating, verified-purchase status, helpful votes, and any photos or videos attached.

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": "B0CX23V2ZK",
    "marketplace": "com",
    "maxResults": 0
  }
}'

# $0.0005 per review returned — maxResults: 0 pulls Amazon's own maximum (100)

Each row returns 29 fields — review text, rating, verifiedPurchase, amazonVine, helpful votes, language, any images/videos attached, plus the product's own aggregate numbers on every row: productRating, productRatingsTotal, and a fiveStar/fourStar/threeStar/twoStar/ oneStar breakdown. You don't have to tally the rating distribution yourself — it's already computed and attached to every review row for that product.

How do you scale from one product to a whole catalog?

urls takes one ASIN or product URL per call, and maxResults tops out at 100 — that's Amazon's own limit, not something Mindcase restricts further. To audit 10,000 reviews, you loop the same call across the ASINs in your catalog, roughly 100 of them at 100 reviews each:

# One call per ASIN — loop this in a shell script, or use the Python/Node examples for a real loop
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": "B0CX23V2ZK", "maxResults": 0}}'

# Repeat for each ASIN — $0.0005 per review × up to 100 reviews per product

Once every product's reviews are in one place, the comparisons a single product page can't show you become possible: which ASIN in the line has the worst rating distribution, whether verifiedPurchase reviews skew differently from unverified ones, or whether a specific defect shows up in the text across multiple variants rather than just one.

How do you spot problems once everything's merged?

You already have the numbers to do this without reading 10,000 reviews by hand. Every row carries the product's own fiveStar/fourStar/ threeStar/twoStar/oneStar counts alongside productReviewsTotal — so a first pass is arithmetic, not reading: compute each ASIN's oneStar share of its total, then sort the catalog by that number. A product sitting well above the catalog average is the one to actually read reviews for first, not the one with the most total reviews or the loudest recent complaint.

From there, narrow by trust signal before you narrow by content: verifiedPurchase and amazonVine tell you whether a review came from someone who actually bought the product versus a review program, and that's worth filtering on before you start looking for text patterns — an unverified 1-star review and a verified one aren't equally informative. Only after that filter does it make sense to scan review text for a recurring term (a specific defect, a packaging complaint) that shows up across more than one ASIN in the line, since that's the signal that something is wrong with the product family and not just one bad run.

What can't you get from Mindcase?

Two cases.

More than 100 reviews for one product. That's Amazon's own cap on what it exposes per product — not a Mindcase limit layered on top. No vendor can pull more than Amazon itself shows.

A rating or verified-purchase filter on the request itself. There's no param for that — every call returns whatever's available up to maxResults, and you filter on the returned rating and verifiedPurchase fields afterward, not at request time.

Which endpoint should you use for which job?

How do you use review data responsibly?

Reviews are public product-page content, but the people behind them aren't. A few practices worth following: don't republish review text attributed to a specific reviewer without checking your use case against Amazon's own terms, treat amazonVine and verifiedPurchase flags as real signal rather than noise to discard, and keep the audit focused on patterns across products rather than singling out individual reviewers.

FAQ