Monitor Competitor Prices Automatically: Setup and Costs

Watch competitor prices on a schedule and hear about the moves that matter. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to search Amazon for "echo dot", and give me a table with the ASIN, title, price, list price, rating, review count and position for each result.

One prompt pulls a competitive set with prices. 1 min setup · 14-30 hrs saved.

You sell something other people also sell, and you want to know when their price moves without opening forty tabs every morning. Most of what comes up for that search is a monitoring product sold by the month. This guide shows a lighter route: your agent pulls the prices on a schedule, you store every record, and a few lines of code decide what counts as a change. We ran both endpoints below live on 2026-10-16 against one Amazon product, so the fields and numbers are what came back. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to monitor competitor prices automatically?

Monid. Install it once, add a key, and your agent calls a price endpoint with a keyword or a product URL and gets the current price back as typed JSON, with no monitoring subscription and no scraper to keep alive.

• Pay for what you run. A search row costs $0.0001 and a single product page read costs $0.02533 (Verified 2026-10-16 on the Amazon tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every tool. The same key and balance call the price endpoints and every other tool on Monid. When you want the reviews behind a price move or the raw page, it is another call on the same balance, not another vendor.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tools are there whenever your agent needs them, on demand, with nothing running between checks. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

A keyword search returned 16 priced products for $0.0016 in our run (Verified 2026-10-16). A single product read costs 253 times as much per call, which is why the search endpoint is the default and the product endpoint is for depth.

How do you pull competitor prices on a schedule?

Run one search call per keyword, once per interval, and append the rows to a table with a timestamp. The search endpoint is /axesso_data/amazon-search-scraper from the provider apify; the product endpoint is /brand/ai/product from context.dev.

Monid fits monitoring because the work is the same call repeated: you pay for the checks you run and nothing between them, and the rows land in your own storage where your own rules read them.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Pull a whole category, not one product

monid run -p apify -e /axesso_data/amazon-search-scraper -w \
  -i '{"input":[{"keyword":"echo dot","domainCode":"com","maxPages":1}]}'

The body is a list, one entry per keyword, and it goes in -i because the endpoint takes a POST body. A keyword search is the right unit for monitoring: one call covers a whole competitive set, it surfaces entrants you were not tracking, and it records position, which a per-product lookup cannot.

Read one product when you need depth

monid run -p context.dev -e /brand/ai/product -w -i '{"url": "https://www.amazon.com/dp/<asin>"}'

This one also takes its input in the body. It first decides whether the URL is a product page, then returns a normalised record. It is not tied to one marketplace, so it is the call to use when your competitive set sits on several sites.

Run it on a schedule

The scheduler is yours. A cron line, a CI schedule or an agent that wakes up on a timer all work, because each run is one CLI call that writes JSON:

mkdir -p snapshots
monid run -p apify -e /axesso_data/amazon-search-scraper -w \
  -i '{"input":[{"keyword":"echo dot","domainCode":"com","maxPages":1}]}' \
  > "snapshots/echo-dot-$(date -u +%Y-%m-%dT%H%M).json"

One file per run, stamped with the time. Nothing in the file is overwritten, so any two runs can be compared later.

📖 See also Connect Claude to Amazon Search Data

How often should you check?

Daily suits most competitive listings: each point in the series is comparable and the cost stays trivial. Check hourly only if something downstream reacts within the hour, such as a repricing engine. Weekly is enough for a monthly positioning review. Whatever you choose, pull everything on the same schedule so the rows are comparable.

Can you build a competitor price tracker yourself with Python?

Yes, and for one or two product pages it is an afternoon. You fetch the page with requests or a headless browser, find the price in the markup and write it to a file. That works until the site changes its layout or starts blocking you.

The cost is everything around the price. You need proxies and block handling for any retailer that dislikes automated visits, a parser per site for the price, the title and the variant, a check that the parsed number is a price and not an empty box, and a repair each time a page changes. The first working version takes hours and the upkeep never ends.

The Monid route is the choice for anything you will run every day. Collection is maintained for you, the output is typed JSON with the price as a number instead of HTML you parse, and a search row is $0.0001 (Verified 2026-10-16). A browser extension is quicker for one product, but it is made for a person looking at a page, not for an agent. Software sold by the month is quicker to switch on than either, and it is the right pick when the finished dashboard is what you want to buy.

What does competitor price data look like, and what can you build with it?

A price record is more than a price. We ran the search endpoint on 2026-10-16 with the keyword echo dot and got 16 rows for $0.0016, one billed unit per row (Verified 2026-10-16). The first row, trimmed:

{
  "asin": "B09B93ZDG4",
  "productDescription": "Echo Dot (newest model) - Vibrant sounding speaker, Designed for Alexa+, ... Deep Sea Blue",
  "price": 79.99,
  "retailPrice": 0,
  "productRating": "4.7 out of 5 stars",
  "countReview": 201006,
  "salesVolume": "10K+ bought in past month",
  "sponsored": false,
  "searchResultPosition": 0,
  "deliveryMessage": "FREE delivery Oct 22 - 26",
  "resultCount": 1000
}

price is a number, retailPrice is the crossed-out list price, sponsored says whether the position was paid for, searchResultPosition counts from 0, and salesVolume is the demand hint the platform publishes.

The product endpoint returned a different shape for the same ASIN: is_product_page: true, platform: "amazon", and a product object with name, price: 79.99 as a number, currency: "USD", features, tags, category, sku and four image URLs. It has no list price and no rank, and it answers one URL per call.

What you can build with it

• A price-change alert. Compare today's rows with yesterday's by ASIN and message yourself only when price moves, using the rule in the next section.
• A position tracker. The same rows carry searchResultPosition and sponsored, so you can see a competitor climb the page and whether they bought the spot. The Amazon PA-API alternative guide shows the search, product and review calls side by side for the same job.
• A promotion log. When retailPrice is above 0 on a row, the gap to price is a discount you can record next to the date.

What goes wrong when you monitor prices automatically?

Five things showed up in the two runs, and each one makes a tracker lie quietly.

Why can two sources agree and still tell different stories?

They agreed on the number. Both the search row and the product page returned 79.99 for the same ASIN. The risk is the field one source has and the other lacks: the product record has no list price at all, and the search record has retailPrice but it was 0 on all 16 of our rows. A tracker that stores one number per product per day cannot tell a cut in what buyers pay from a change in the reference price a discount is computed against. Those are opposite signals, so store the whole record and let the rule below read two fields.

Why does a retailPrice of 0 mean "no list price"?

Because 0 is not a price. All 16 rows carried retailPrice: 0, and no row carried a list price. Treat 0 as missing, not as a free list price, or every discount calculation divides by nothing. In Python, normalise it on the way in:

def clean(row):
    list_price = row.get("retailPrice") or None   # 0 -> None
    return {"asin": row["asin"], "price": row["price"], "list": list_price,
            "sponsored": row["sponsored"], "pos": row["searchResultPosition"]}

Which rows are not your competitor?

Most of them. A keyword returns neighbours: of the 16 echo dot rows, 11 were other devices (Echo Dot Max, Echo Dot Kids, Echo Spot and Echo Show), priced from 89.99 to 249.99, and 2 were two-packs of the product itself. The two-packs, at positions 3 and 6, were at 159.98, which is the single-unit price doubled, not a rival who charges twice as much. Compare a row with its own earlier self by asin, never with the cheapest or the first row, or the day the order reshuffles your tracker records another product's price under yours.

Why does one product show up as several ASINs?

Colours and sizes are separate ASINs. The Deep Sea Blue, Charcoal and Glacier White Echo Dot were rows 0, 1 and 2, each with its own ASIN, the same 79.99 and the same countReview of 201006. Decide early whether your unit is the parent product or the specific variant, record the asin you actually fetched, and never compare across the two. For the missing-value cases on the detail side, best Amazon reviews API covers the review side of a variant, which is where the shared countReview matters.

Why can the product endpoint hand you yesterday's price?

Because it can reuse a cached result. The input schema has a maxAgeMs field, and the default reuses a result younger than one day; setting it to 0 forces a fresh fetch. For a daily tracker, pass maxAgeMs explicitly so the date on your row is the date of the price.

The rule these produce

Store the whole record, then diff fields, not one number:

WATCH = ("price", "list", "sponsored", "pos")

def changes(prev, cur):
    return {f: (prev.get(f), cur.get(f))
            for f in WATCH if prev.get(f) != cur.get(f)}

ev = changes(yesterday[asin], today[asin])
if "price" in ev and "list" not in ev:
    alert("price moved", ev)          # the competitive event
elif "list" in ev:
    log("reference price changed", ev)

A move in price with the list price unchanged is the event worth waking up for. Storage is the cheapest part of this pipeline, and a field you discarded cannot be recovered later, the same argument made for storing the position with every rank check.

Which endpoint should I use for which job?

Prices Verified 2026-10-16 with monid inspect. Use the search endpoint to watch a set and the product endpoint when the competitor is not on Amazon or you need the product description. The search endpoint bills per row, and the number of rows per page is not fixed: our one page held 16, so $0.0016. Size a job as keywords times rows times the unit price, and expect the row count to move. Checking five keywords a day at 16 rows each is 80 rows, or $0.008 a day.

When is another route a better fit?

You need a finished dashboard and alerts. Monitoring software sold by the month gives you a screen, a user list and an inbox, and building those is more work than the data. If nobody on your team will write the diff rule, buy the screen.

You cannot act on the answer. If prices are set quarterly by a committee, a daily feed changes nothing.

You match products by name. Across retailers the same item has different titles, bundles and pack sizes, and name matching compares things that are not the same product, as the two-packs above show. Solve identity first with a GTIN, EAN, UPC or model number, or the series is fiction.

You are tempted to coordinate. Watching a competitor's published price is research. Agreeing with a competitor about prices is a different matter, and rules differ by country, so check yours and keep the system observational.

And the disclosure: this is Monid's blog and we sell access to the endpoints above. The most useful idea here, storing the whole record and diffing two fields, is code you write yourself and works with any data source.

Conclusion

The quickest way to monitor competitor prices automatically is a scheduled keyword search through Monid: $0.0001 a row (Verified 2026-10-16), one key for this and every other tool, about a minute to set up and ready inside your agent whenever you need it. Building a scraper yourself works for a few pages and costs hours of parsing and repair; Monid keeps the collection maintained.

Two things matter more than the endpoint. Store the whole record, not one number, and treat a retailPrice of 0 as missing. And compare a product with its own history by asin, because a keyword search returns neighbours, packs and colour variants that look like rivals and are not.

How we estimated the time saved: building and running your own tracker is roughly 6 to 12 hours for the fetch and parsing layer across a few sites, 4 to 8 hours for storage, change rules and alerts, and 4 to 10 hours for the first month of upkeep as pages change. That is 14 to 30 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p apify -e /axesso_data/amazon-search-scraper, make one call for a keyword in your market, and count how many rows carry a retailPrice above 0. It costs about $0.0016 (Verified 2026-10-16). Start at monid.ai.

FAQ

Published September 2026.