Amazon Product Data API - Search, Prices, Offers, Bestsellers

Turn a list of search terms or ASINs into a dataset from any of 24 Amazon marketplaces: what ranks, what it costs, who sells it, how it is rated, and what sits next to it.

What it collects

• Search and browse: search results for a keyword with sort order, category, refinement and sponsored filters; category listings by category id or URL; bestseller pages including new releases, movers and shakers, most wished for and gift ideas; deals pages filtered by deal type, price tier, discount, Prime access and rating.
• Product pages: one product by ASIN, GTIN, EAN, UPC, ISBN or URL, with title, brand, buy box price and availability, rating and rating breakdown, images and videos, feature bullets, specifications, attributes, variants and their prices, bestseller ranks, A plus content, book formats and editions, and the also viewed, also bought and frequently bought together lists.
• Offers and stock: every seller offer for a product with price, condition, Prime eligibility, delivery and seller details; a stock estimate read from the shopping cart for the buy box winner or one named offer.
• Sellers and reviewers: a seller's profile with its feedback summary, pages of customer feedback for a seller, a seller's whole catalogue with refinements, and a reviewer's profile with their first pages of reviews.
• Stores, charts, wishlists and authors: the products on a brand store page, the entries on an Amazon Charts page, the items on a public wishlist, and an author's titles by format and sort order.
• Lookups: autocomplete suggestions for a search term by department, GTIN, EAN, UPC and ISBN codes for an ASIN, and the category tree with standard, bestseller and deals category ids to feed the other services.
• Your account: plan, credits used and remaining, reset date and platform status, free at the provider.

FAQ

What is an Amazon product data API used for?

Reading Amazon at a scale a browser cannot. A brand tracks the buy box price and the sellers on its own ASINs every morning across six marketplaces. A seller reads the first three pages of search results for its keywords and the bestseller page for its category to see where it ranks. A price comparison product pulls product pages by GTIN so it can match Amazon listings to its own catalogue. An analyst reads a competitor's whole seller catalogue and feedback history. The common shape is a list of terms or identifiers in and a table of structured records out, which is exactly what this actor is.

How do I tell it what to read?

Pick a service, then give it lines. Search and autocomplete read search terms, one per line. Every other service reads identifiers, one per line: an ASIN for product, offers, also bought, shop by look, stock estimate and ASIN to GTIN; a seller id for the seller services; a reviewer id, brand store id or wishlist id for those; a category id for bestsellers, category and deals. A line that starts with http is sent as that page's URL wherever the service accepts one, and a 12 to 14 digit line is sent as a GTIN where the service converts them. Each line is sent as exactly one identifier kind, because a wrongly typed identifier is a charged request about the wrong thing, and you can set the kind explicitly when a line could be mistaken.

Where do category ids and seller ids come from?

From the actor itself. The category tree service lists the root categories of a marketplace, the children of any parent, or every category whose name contains a search term, in standard, bestseller or deals flavours, and each row carries the id the other services take. Seller ids and offer ids come back on every row of the offers service, reviewer ids on reviews, brand store ids and URLs on product pages, and format ids on author pages.

What happens to an ASIN with no data?

It becomes its own row, marked found: false, with the provider's own explanation in the note: the product is not on that marketplace, the request combined parameters the provider does not support, or the provider's parser for that request type is temporarily unavailable. That last case is reported with the provider's suggested wait and is never charged, and the remaining identifiers in the run are recorded as not attempted rather than sent into the same incident. A run over a hundred ASINs therefore returns a hundred rows rather than eighty-eight, and you can see at a glance which twelve were empty.

How does paging work?

Two ways, and you choose. Set pages per identifier and the actor walks a listing page by page, one request per page, stopping when the provider reports no further page or the maximum results is reached; wishlists, which scroll rather than number their pages, are followed by the token the provider hands back. Or set the provider-side max page, up to five, and the provider reads and concatenates the pages in one request, marking each entry with the page it came from. Either way the provider charges one credit per page actually returned.

Can this actor spend money beyond the data call?

No. The provider also publishes routes that create and start collections of thousands of requests, add zipcodes to an account and configure upload destinations, and none of them is wired up anywhere in this actor. Every route it can reach is a read: the real-time request endpoint, the categories reference and the account summary. That is a deliberate limit, because a scheduled run that could enqueue fifteen thousand requests on your plan is a scheduled run that eventually will.

Which request types are missing, and why?

Reviews, review comments, questions, question answers, sales estimation and formats and editions. The provider lists all six as request types but has unpublished their parameter pages, so their filters cannot be read from the documentation, and this actor does not invent parameters. The extra query parameters input passes anything the provider documents for a wired service through verbatim, but it does not add request types.

Which routes were checked against the live API?

All three. On 2026-09-24 the request, categories and account routes each answered a deliberately invalid key with the provider's own 401 envelope, while an invented path answered a bare 404, which is what confirms the route table. The request and result field names come from the provider's published reference for each request type. No real data was read while building this actor, so it is not live-tested against a paid key, and the provider's example responses are the only guide to what a record looks like.

Do I need my own API key?

Yes. This actor is bring-your-own-key and never ships a key of its own. Paste the key from your provider account, or set it once as the DATA_API_KEY environment secret. The provider documents one way to send it, as the api_key query parameter, so that is how it travels; be aware that this puts the key in the request URL on the provider's side, which is the provider's design rather than this actor's choice.

What does it cost?

Pay per result. A full page record, which is a whole product page, seller profile, reviewer profile or stock estimate, costs the most, because one row is a complete answer about one thing. A listing entry, which is one search result, offer, bestseller, deal, feedback entry or store product, costs a third of that, because one request commonly returns dozens. A lookup row, which is one autocomplete suggestion, one GTIN or one category, costs half that again. Reading your own account is priced near zero. Platform usage is included, and identifiers the provider returns nothing for are never charged. Your provider account is charged separately by the provider, one credit per page and more for the product options that say so.

How fast will it run?

The provider's rate limit depends on your plan and is not published as one number, so the actor defaults to thirty requests a minute and lets you raise it. A rate limit refusal is retried against the provider's own Retry-After header rather than a guessed delay, and a server error is retried with backoff before the run is failed.

Example output

{
  "service": "search",
  "serviceLabel": "Search results",
  "amazonDomain": "amazon.com",
  "requested": "memory cards",
  "requestedAs": "search_term",
  "page": 1,
  "found": true,
  "recordType": "item",
  "asin": "B09X7BK27V",
  "title": "SanDisk 128GB Extreme microSDXC UHS-I Memory Card with Adapter",
  "link": "https://www.amazon.com/dp/B09X7BK27V",
  "price": { "symbol": "$", "value": 16.99, "currency": "USD", "raw": "$16.99" },
  "rating": 4.8,
  "ratingsTotal": 210433,
  "retrievedAt": "2026-09-24T09:14:52.118Z",
  "record": { "...": "every field the provider published for this result, unchanged" },
  "note": null
}

Keyword map

Amazon product data API, Amazon search results API, Amazon product API, Amazon price API, Amazon buy box API, Amazon offers API, Amazon seller data API, Amazon bestsellers API, Amazon category API, Amazon deals API, Amazon brand store data, Amazon wishlist data, Amazon charts data, ASIN lookup API, GTIN to ASIN, UPC to ASIN, ASIN to GTIN, EAN to ASIN, ISBN to ASIN, Amazon product details by ASIN, Amazon stock estimation, Amazon autocomplete API, Amazon marketplace data, ecommerce product data API, competitor price monitoring Amazon, Amazon scraper API alternative, Amazon data for 24 marketplaces.