Build an Amazon Review Monitor: ratings, complaint signals, and review media

#webscraping #api #tutorial #automation

Amazon review data is useful only when it can answer a decision: has a new quality issue emerged, what do verified buyers say, and is there visual evidence behind it? This guide shows a small, production-oriented pattern for collecting reviews, flagging complaint risk, and storing the fields needed for follow-up analysis.

The example uses the Pangolinfo Amazon Review API. It returns structured review records rather than page HTML, including star rating, title, text, verified-purchase status, helpful votes, product variant data, review images, and review video URLs.

1. Decide what to monitor

Start with a target ASIN and a clear observation rule. A useful baseline is:

retrieve the most recent page of reviews every day;
retrieve one-star reviews separately to surface issues early;
preserve image and video URLs for review validation;
keep the review ID and date so repeated runs can be deduplicated.

This keeps the workflow focused on new customer feedback instead of reprocessing the entire review history.

2. Make a structured review request

Create a Pangolinfo API Key in the Console, then make the request below. Do not put a production key into shared workflows, browser code, or public collections.

curl --request POST \
  --url https://scrapeapi.pangolinfo.com/api/v1/scrape \
  --header 'Authorization: Bearer YOUR_PANGOLINFO_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "url": "https://www.amazon.com/dp/B076CLQDR4",
    "site": "",
    "bizContext": {
      "bizKey": "review",
      "pageCount": 1,
      "asin": "B076CLQDR4",
      "filterByStar": "one_star",
      "sortBy": "recent"
    },
    "format": "json",
    "formatType": "all_formats",
    "mediaType": "all_contents",
    "parserName": "amzReviewV2"
  }'

The same endpoint supports all_stars when you need a broad feedback sample. Full request and response fields are documented in the Amazon Review API reference.

3. Persist only the fields that drive decisions

For each record in data.json[].data.results[], store at least:

Field	Why it matters
`reviewId`	Deduplicate repeated scheduled runs.
`star`, `title`, `content`	Detect rating shifts and complaint themes.
`date`, `country`	Attribute changes to a time period and marketplace.
`purchased`, `vineVoice`	Separate verified-buyer feedback from other sources.
`helpful`	Prioritize issues readers find useful.
`imgs`, `videos`	Preserve evidence for quality and listing reviews.
`attributes`, `asin`	Identify a problematic size, color, or variant.

4. Turn raw reviews into alerts

A simple alert rule is more robust than a generic sentiment score:

Alert when a new verified one-star review has an image or video.
Alert when two or more reviews in the same run mention the same failure mode.
Include ASIN, review ID, rating, title, date, and evidence URLs in the alert.
Add a cooldown key such as asin:reviewId so the same review is not sent twice.

For no-code automation, the Pangolinfo n8n node and public Postman Amazon Review API collection provide starting points.

5. Use the MCP route for agent workflows

If an agent needs to combine reviews with product, keyword, niche, and AI-search data, use Amazon Data MCP instead of maintaining separate parsers. The MCP server exposes the review capability alongside the broader Amazon and AI-search toolset, while your application keeps control of its own API key and usage limits.

Practical takeaway

An effective review monitor is not an endless scrape. It is a small, repeatable process: collect recent structured feedback, retain identifiers and evidence, detect new recurring issues, and send a deduplicated alert to the team that can act on it.

DEV Community