Wire Up Amazon Search Rank Tracking in One Script

Copy this line to your agent to start tracking Amazon search rank for a keyword.

set up https://monid.ai/SKILL.md and use apify/axesso_data/amazon-search-scraper to track the top Amazon results for a keyword over time

You can snapshot the top Amazon results for any keyword, with rank, price, rating count and Prime status, from a single metered endpoint, then run that snapshot on a schedule to watch a category move. This is the whole cookbook: the query, paging, flattening each result into a dated row, and the cron line that appends one snapshot a day. Monid is the OpenRouter for agent tools, so this endpoint is one of over a thousand reachable on one key, and we verified this one ourselves on 2026-08-17.

What is the best API for Amazon product data?

For search rank specifically, the official answer stopped existing and the useful answer is a search-results scrape. That needs explaining, because the retired option still shapes what people expect.

The Product Advertising API was never a ranking feed

Amazon's Product Advertising API was the official route and it retired in May 2026. Even while it ran, its SearchItems operation sat behind Associates approval tied to qualifying sales, and what it returned was an affiliate-shaped product list rather than the page a shopper sees. Position and sponsored placement, the two fields a rank tracker exists to record, were not in it.

So "what is the best API for Amazon product data" splits by job. If you need catalogue attributes for products you already know, an ASIN lookup is the cleaner shape and automating product-detail lookups from a list of ASINs covers it. If you need to know where something ranks for a keyword, you need the search page as rendered.

What a search feed has to return to be worth scheduling

Four fields decide whether a snapshot is chartable later.

• Position, and whether the slot was sponsored. Without the sponsored flag, a paid placement looks like an organic win and every chart built on it is wrong.
• ASIN. The join key across snapshots. Titles change, ASINs do not.
• Price and rating count at the moment of capture. These move faster than rank and explain most of the rank movement you will see.
• The capture timestamp. The field people leave out and then cannot reconstruct.

apify/axesso_data/amazon-search-scraper, maintained by scraping specialists on Apify, returns all four plus availability, Prime status, images, category hierarchy and similar-keyword suggestions.

How can I scrape only price, stock and availability from Amazon every day?

One metered call per keyword, flattened into a dated row, on a schedule. Five steps, and the third is the one that decides whether you end up with a chart or a folder of JSON.

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-key> -l main

Step 1. Inspect before running

What it does. Returns the input schema, the billing shape and the price, for free.

The call.

monid inspect -p apify -e /axesso_data/amazon-search-scraper

What comes back. The input is an array wrapped in one input key, which is the shape people get wrong on the first try:

{"input":[{"keyword":"wireless earbuds","domainCode":"com","maxPages":1,"category":"aps"}]}

What it costs. Nothing. discover and inspect are both free, so reading the schema and the price before committing costs you nothing at all.

Step 2. Run one keyword, one page

What it does. Fetches the rendered search page and returns structured items.

The call.

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

What comes back. One item per search result: ASIN, title, position, price with any discount, star rating, review count, a sponsored flag, availability and Prime status. Page-level extras arrive too, including similar-keyword suggestions, which is a free source of adjacent terms to track next.

What it costs. Billed per result, and here is the part worth reading twice: maxPages caps pages, not results. Each page holds a variable number of items, so the result count for a given run is not something you can predict from the input. Start at one page, count what came back, and only then decide the cadence. Magnitudes are at monid.ai/tools.

Step 3. Flatten each result into a dated row

What it does. Turns a payload into something you can compare against yesterday.

Keep it narrow on purpose. One row per result, and the date is part of the row rather than the filename:

monid runs get -r <RunID> -o snapshot.json

jq -r --arg d "$(date -u +%F)" '
  .[] | [$d, .keyword, .position, .asin, .title, .price, .reviewCount, .sponsored]
  | @csv' snapshot.json >> history.csv

Why the date goes in the row. A folder of 2026-08-17.json files is a backup, not a history. The moment the date is a column, the whole file is one GROUP BY away from a rank chart, and a re-run on the same day is visible instead of silently overwriting.

Step 4. Append, never overwrite

What it does. Makes the history the artifact and each run disposable.

>> rather than > is the entire trick. Every run adds rows, nothing rewrites them, and the file only grows. If a run fails halfway you get a short day rather than a corrupted history, which is the failure mode you want.

Step 5. Put it on a schedule

What it does. Turns a snapshot into a trend.

# 07:00 UTC daily
0 7 * * * cd ~/rank-tracker && ./snapshot.sh >> cron.log 2>&1

Daily is the right default for rank. Price moves faster, so if price is the thing you actually care about, run twice a day and accept that the rank column is then oversampled. Do not go hourly on a whim: this is metered per result, and a cadence you picked casually shows up on the bill.

📖 See also Amazon's PA-API Retires in 2026: How to Move

Which endpoint should I use for which job?

Three Amazon jobs, three shapes, and picking by job rather than by vendor is most of the decision. Every row below was checked with monid inspect on 2026-08-17.

The column that matters is the last one. Search and reviews are both per result with an unpredictable multiplier, so both need a small real run before you size a schedule. The ASIN lookup is the only one of the three where the input count equals the billed count, which makes it the easy one to budget and the reason it belongs in any pipeline where you already know the products.

That difference also decides the order to build in. Start from the ASIN lookup for the catalogue you own, add search tracking for the terms you compete on, and add reviews last, because it is the one whose volume surprises people.

What does tracking one keyword actually cost?

Per result, which for a rank tracker means the bill is a function of how many keywords you track and how deep you page, not how long anything runs and not how many people on your team look at the chart.

Three levers, in the order they matter:

Keyword count. Every entry in the input array is its own query, billed separately. This is the dial you will actually turn.

Page depth. maxPages multiplies results per keyword, and because per-page item counts vary, depth is also where cost predictability goes. One page is the top of the search results, which is where rank tracking lives anyway.

Cadence. Daily against hourly is a twenty-four times difference in a bill for a metric that does not move that fast.

The honest way to size this is to run one keyword at one page, look at how many results came back, and multiply. That is two free calls and one cheap one, and it beats any estimate. Current magnitudes are at monid.ai/tools, and inspect shows the figure before anything bills.

::skill-prompt{prompt="track the top Amazon results for "wireless earbuds" daily and append each snapshot to a dated CSV"} ::

When should you not use a search scrape?

Three cases, and the first two are common.

You only need attributes for products you already know. Then this is the wrong shape and you are paying for a search you did not need. Use an ASIN lookup instead.

You need reviews at volume. A search scrape returns review counts, not reviews. That is a different endpoint family with a different billing shape, and we tested them separately in the Amazon reviews API comparison, including one listing whose billing did not match its description.

You need a contractual guarantee about availability. A scrape reads the page as a visitor sees it. Amazon can change that page, geo-vary it, or serve a different result set to a different exit location. domainCode targets a marketplace, not a city, so if your question is local availability, this is an approximation.

And the caution about our own layer: what an endpoint's listing claims about billing has not always matched what it charges. We found that on a different Amazon endpoint and published it rather than quietly fixing the page. Until every listing is verified, the working rule is that inspect tells you what an endpoint claims and a small real run tells you what it charges. That rule is why Step 2 above says to count what came back.

Conclusion

Rank tracking is not a scraping problem, it is a schema-and-cadence problem. The scrape is one call. What decides whether you have a rank history in three months is whether the date went into the row, whether you appended instead of overwrote, and whether you picked the cadence deliberately rather than defaulting to hourly.

Run one keyword at one page first. Count the results, then decide everything else.

FAQ

Last updated August 2026.