Connect Claude to Amazon Search Data: OpenWeb Ninja and Monid
Amazon has no keyword API for sellers. Here is what a search endpoint actually returns, how to hand it to an agent, and which route fits which job.
An Amazon seller asked a question on r/AmazonSellingSoftware that has no clean answer: how do you connect Claude to Amazon keyword and competitor sales data. It sounds like it should be a solved problem. It is not, and the reason is worth stating before any code.
Amazon publishes no keyword API for sellers. Seller Central shows you your own performance, the Product Advertising API retired in May 2026 and never returned competitor data anyway, and the Selling Partner API is scoped to your own account. Everything about what your competitors rank for, what a category looks like today, and which listings own a keyword comes from reading the search results page.
So the real question is not which official API to use. It is which search endpoint to call, what it gives back, and how to put that in front of an agent.
Fair disclosure: you are on the Monid blog, one of the routes below is ours, and the other belongs to a company that replied to a partnership email. Both are described as they are, including the part where the second one is not in our catalogue.
How do I connect Claude to Amazon keyword and competitor sales data?
Point the agent at a search endpoint and let it call one per keyword.
The connection itself is the easy half now. Monid is the OpenRouter for agent tools, so it ships as a remote MCP server and an agent reaches the whole catalogue through one key:
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 discover, inspect and run by itself. More detail in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>
More in the CLI quickstart.
The harder half is knowing what to ask for. "Competitor sales data" does not exist as a field anywhere, because Amazon does not publish unit sales. What exists is a set of proxies a search result carries: rank position for a keyword, review count, rating, price, and whether a listing holds a badge. Those move with sales, which is why sellers read them. An agent that understands it is reading proxies rather than sales figures will give you better answers than one that thinks it found revenue.
What actually comes back from one keyword search?
More than most people expect, and the extra fields are the useful part.
We ran the Amazon search endpoint on 2026-08-19 against a single keyword, one page:
monid inspect -p apify -e /axesso_data/amazon-search-scraper
monid run -p apify -e /axesso_data/amazon-search-scraper \
-i '{"input":[{"domainCode":"com","keyword":"standing desk","numPages":1,"sortBy":"relevanceblender"}]}'
One page returned 48 product records. Each carries the ASIN, the title, price, rating, review count and position in the result set. That much is expected. Three fields alongside them are what make this useful for the question above:
similarKeywords. Amazon's own related-term suggestions for the query, returned with the results. This is the closest public thing to a keyword tool, and it comes free with a search you were making anyway.browseNodeandnodeHierarchy. The category path Amazon filed the results under, so an agent can tell whether a keyword sits in the category you think it does.resultCount. How many listings compete for the term in total, which is the difference between a keyword worth chasing and one already saturated.
Read those three together and you have the shape of a keyword: what it is adjacent to, where it lives, and how crowded it is. Read the 48 rows and you have who currently owns it.
One caution on resultCount, because it is the field most likely to be misread. Amazon's reported total is an estimate and it moves between queries for reasons that have nothing to do with the market. Treat it as an order of magnitude, not a metric: the difference between four hundred results and forty thousand is real and worth acting on, the difference between twelve thousand and thirteen thousand is noise. The same caution applies to reading rank position on a single pull, since results are personalised and regionalised. One snapshot tells you the shape of a category. Only repeated snapshots tell you a direction.
What an agent does with that is the part worth designing. The useful loop is not "search and summarise", it is search, then decide what deserves a second call. Rank position plus review count tells you which listings are established and which are new and climbing; the climbing ones are usually where a category is actually moving. An agent can flag those, pull full product details for just those ASINs, and leave the other forty alone. That two-stage shape, cheap wide read then narrow deep read, is what keeps a keyword sweep from turning into a bill.
If rank position over time is the thing you care about rather than a snapshot, wiring up Amazon search rank tracking is the scheduled version of the same call.
Possible to scrape Amazon for just price, stock and availability daily?
Yes, and the mistake is doing it with a search call.
A search endpoint is the right tool for discovery, when you do not yet know which ASINs matter. Once you have the list, searching again every day is the expensive way to ask a cheap question. Switch to a product-details call keyed by ASIN, which returns the fields you are watching without paying for 47 listings you already decided to ignore.
The daily pipeline half of this, including how to diff snapshots so you only alert on change, is worked through in the PA-API migration guide, and buying versus building an ASIN feed covers the case where you are weighing a managed endpoint against your own infrastructure. What matters here is the agent-shaped version: discovery is a search call, monitoring is a details call, and an agent that reaches for the same endpoint for both jobs will quietly overspend.
Catalogue or specialist: which route fits?
Two different shapes, and the honest answer is that it depends on whether Amazon is your whole product.
Through a catalogue. The route above. One key reaches Amazon search, reviews, product details and seller data, alongside every non-Amazon tool the same agent needs. Discovery and schema inspection are free, calls are billed per result from one balance, and no separate signup exists per vendor. This wins when Amazon is one of several things your agent does, and when you cannot list in advance everything it will need.
Through a specialist. OpenWeb Ninja is the shape on the other side: an API that does Amazon and does it deeply. Product details, offers, reviews, search, best sellers, deals, seller profiles, and influencer endpoints that most Amazon APIs do not carry at all. It covers 24 marketplaces through a country parameter, from US and GB through to JP, IN, BR and ZA, which matters if you sell in more than one region and want the same call shape for each.
Their docs are also worth reading as an example of the thing to look for. They state outright that Amazon now requires a logged-in session to load reviews past the first page, so the public endpoint returns the eight reviews Amazon shows without one, and deeper pulls take a cookie parameter. A vendor that writes its own ceiling into the reference is easier to build against than one that implies there is none, because you find out at design time rather than when a batch comes back short.
To be clear about our own position: OpenWeb Ninja is not in the Monid catalogue. We are describing a route you would take directly with them, not something you can reach through us today. If Amazon is the core of what you are building, going direct to a specialist and holding that one relationship is a perfectly good answer, and often the better one.
There is a second axis people miss, which is who absorbs breakage. Amazon changes its result markup regularly, and when it does, something has to be fixed. With either route that maintenance is the provider's, not yours, which is the actual argument for both of them over a scraper you own. The difference is only how many such relationships you hold: one deep one, or one that fans out. Neither removes the work, they relocate it.
The split in one line: a catalogue is for an agent that cannot predict what it will need, a specialist is for a product that already knows.
What does a keyword sweep cost?
Per result, which is the number that surprises people.
The measured run above billed 48 units for one page, because the endpoint charges per record returned rather than per query. That is the right mental model for sizing a job: a hundred keywords at one page each is not a hundred calls, it is roughly forty-eight hundred results. Still small in absolute terms, and the whole sweep lands in single-digit dollars, but it is not the flat per-query price the word "search" suggests.
Two habits follow from that. Bound numPages deliberately rather than leaving it at a default, and run one keyword before you run a hundred. Free inspect shows the billing shape before you spend anything, and current prices are on monid.ai/tools rather than in this sentence, where they would go stale.
The same per-result mechanic caught us out once already on the reviews endpoint, and we corrected it in public rather than leave an under-quote standing.
When is this the wrong approach?
When you need numbers Amazon does not publish.
It is also worth being blunt about a category of tool this article does not replace. Dedicated seller-intelligence products model estimated sales from the same public signals and add their own historical panels on top; if you want that modelling done for you and are willing to pay a subscription for it, buy one. What this route gives you is the raw signal, priced per call, in a form an agent can act on without a seat licence. Those are different products and it is worth knowing which one your question actually needs.
Nothing here returns unit sales, revenue, or conversion rate, and any tool claiming to sell you those is modelling them from the same public signals you can read yourself. If your decision needs actual sales figures, the honest answer is that they are only available for your own account, through Seller Central and the Selling Partner API.
It is also the wrong approach if you need one ASIN watched continuously rather than a category surveyed. Polling a search endpoint for a listing you already know is paying discovery prices for a monitoring job.
And if Amazon is genuinely all you do, the catalogue argument gets weaker. One deep integration with a specialist beats a general layer you use for a single vendor, which is why the routes section above says so plainly rather than pretending otherwise.
FAQ
Does Amazon have an official keyword API for sellers?
No. Seller Central reports on your own listings, and the Selling Partner API is scoped to your own account. There is no official endpoint that tells you what competitors rank for. Every tool offering that reads it from public search results, including the ones that dress it up as proprietary data.
Is scraping Amazon search results allowed?
Search result pages are public and readable without a login, which is different from a licence to do anything with what you collect. Amazon's terms, your jurisdiction, and how you store and use the data all still apply. A managed endpoint reads the public page from the provider's own infrastructure rather than from your address, which removes the account-level risk but not the compliance question.
Can I get results from Amazon marketplaces outside the US?
Yes. The endpoint used above takes a domainCode, and specialists like OpenWeb Ninja expose the same idea as a country parameter across two dozen marketplaces. If you sell in several regions, confirm the parameter name and the coverage list before you build, because they differ by provider and a missing market is usually discovered late.
How do I read Best Sellers Rank from a listing?
It arrives inside the product information block on a details call rather than as a top-level field, and it is absent when Amazon does not display it for that product. Treat it as present-or-not rather than as a guaranteed column, and read the category it names, since a rank of one in a narrow subcategory and a rank of one overall are very different claims.
Last updated August 2026.
