Amazon's PA-API Retires in 2026: How to Move to Monid

Amazon retired PA-API v5 on May 15, 2026. If your app still signs requests with AWS Signature V4, it stopped returning data months ago. This is how to rebuild those calls, which replacement actually works, and which one we had been recommending that does not.

That last part is the reason this guide was updated. We re-ran every endpoint it recommends on 2026-08-12 and one of them now returns empty prices. We have changed the recommendation and left the evidence in, because a migration guide that sends you to a dead field is worse than no guide.

Do I actually have to migrate?

Yes, if your app called PA-API v5 after May 15, 2026. The endpoint is retired and the old auth is rejected, so requests fail regardless of which fields you were reading.

Three dates mattered and they did not arrive together.

• January 31, 2026: the Offers V1 resource was cut off first. If you read buy-box prices or offer listings, this was your earliest deadline, months before the rest.
• April 30, 2026: PA-API v5 was deprecated. Amazon's recommended migration cutoff, after which assume no fixes and no support.
• May 15, 2026: the v5 endpoint was retired. Requests signed with AWS Signature V4 are rejected, with no grace period.

The auth is the part that makes a small dependency expensive to move. PA-API signed every request with AWS Signature V4 against keys tied to an Associates account, so even where every field you read still exists somewhere, the signing path itself is gone. Any migration is at minimum an auth rewrite. Details are in the PA-API documentation and this auth-layer writeup.

Before migrating anything, list what you actually call. Most integrations lean on three things: GetItems for titles, prices, images and availability; SearchItems for keyword-to-product listings; and CustomerReviews for the star average and rating count, which is all PA-API ever returned about reviews. There was never review text, and the Creators API keeps that limit.

What is the best API for Amazon product data?

The one that returns populated fields today, which is not always the one whose description reads best. Here is what we measured.

The search endpoint works and carries prices

apify /axesso_data/amazon-search-scraper is the SearchItems replacement, and on 2026-08-12 it was the strongest performer of the set:

monid inspect -p apify -e /axesso_data/amazon-search-scraper
monid run -p apify -e /axesso_data/amazon-search-scraper \
  -i '{"input":[{"keyword":"macbook pro 16","domainCode":"com","page":1}]}'

One keyword returned 22 product rows, every one of them carrying a price, plus ASIN, star rating, review count, Prime flag, sponsored flag, delivery message, sales volume and the result position. The charge came to exactly twenty-two times the per-result price, so the billing matched the listing.

Because it returns a price per row, this endpoint doubles as a price source even when you are not really searching: a keyword narrow enough to surface your ASIN gets you its current price and rating in one cheap call. Match on the ASIN, never on the position. More on why in the daily-tracking section below, because getting this wrong stores another product's price under your own.

The product-details endpoint is currently returning empty fields

This is the correction. The previous version of this guide recommended apify /delicious_zebu/amazon-product-details-scraper as the GetItems replacement, describing it as returning "pricing, list price, discounts, availability, star rating, rating distribution, best-seller rank, categories, brand, and images."

We ran it against two ASINs on 2026-08-12. Both charged the full per-result price. Both came back substantially empty.

On the first ASIN, 14 of 26 fields were blank, including every commercially useful one:

empty:   price, list_price, availability, rating_stars, rating_distribution,
         best_sellers_rank, seller_name, manufacturer, delivery_date,
         product_description, customer_review_summary, breadcrumbs,
         recent_purchases, fastest_delivery_date
populated: asin, title, brand_name, rating_count, images, about_item,
         model_number, default_variant, product_url, brand_page_url,
         seller_page_url, scrape_time

The second ASIN came back with an empty title as well.

You are charged either way. A result with no price is still a result, and the bill does not know the difference. So: do not use this endpoint for price or availability right now. Use the search endpoint above, which returns both. If you need the richer per-ASIN record, run one call and read the fields before you wire it into anything.

We are naming our own catalogue here because the alternative is leaving a recommendation up that quietly returns nothing for the field most readers came for.

Reviews: the upgrade PA-API never gave you

Since you were never getting review text from Amazon, moving off PA-API is the moment you can finally read it. apify /axesso_data/amazon-reviews-scraper returns each review's full text, verified-purchase flag, date and helpful votes.

One correction carries over from the reviews comparison: that endpoint is described as returning one result per query, and a measured run billed per review instead. Fifty reviews cost fifty results. Set maxPages deliberately.

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

Pull the narrowest thing that carries the number, and schedule it.

This is one of the most common questions in the category, and it is a different job from a full product record. You do not want the description, the images or the review text. You want three fields to diff against yesterday.

Given what we measured above, the cheapest reliable route today is the search endpoint with a keyword tight enough to return your ASIN, reading price and productRating off the matching row. It is the cheapest Amazon call in the catalogue by a wide margin, and a daily check across a hundred tracked products is a rounding error. Current figures at monid.ai/tools.

Match the ASIN, or you will store the wrong product's price

This is the part to get right, because the failure is silent and the data looks fine.

A keyword search returns whatever Amazon decides is relevant: sponsored placements, a different capacity or colour of your product, a competitor, a case for the thing rather than the thing. Reading the price off the first row, or off a fixed position, means that the day Amazon reshuffles results your tracker records someone else's price under your ASIN and keeps doing it until a human notices.

So the rule is: filter the returned rows to asin == <your tracked ASIN>, and if no row matches, record nothing and move on. A missing data point is honest. An inferred one corrupts the series, and price history is exactly the kind of data nobody re-checks once it is stored.

row = next((r for r in rows if r["asin"] == tracked_asin), None)
if row is None:
    log.warning("no exact match for %s on %r, skipping", tracked_asin, keyword)
else:
    store(tracked_asin, row["price"], row["searchResultPosition"])

Two smaller notes. Rows carry a searchResultPosition, so once you have matched the ASIN the same call also tells you where your listing ranks for that keyword, which is worth storing alongside the price. And availability is the field most likely to be missing or vague across all these endpoints, so verify it on your own ASINs before building an out-of-stock alert on it.

Is a managed scraping API worth it, or should I build in house?

Buy it, and the PA-API retirement is itself the argument.

The instinct after a vendor removes an API from under you is to own the pipeline so it cannot happen again. It is the wrong lesson. Building your own Amazon scraper means proxies, CAPTCHAs, a login wall and a parser you rewrite on Amazon's schedule; one developer's post in this space is just the title "Amazon denied my API access, so I built my own scraper" and a link to the library they now maintain forever.

The right lesson is about coupling, not ownership. What hurt was that one source was wired directly into your product. A layer with the provider and endpoint as parameters means a dead endpoint is a flag change rather than another migration project, and this guide is an example: the product-details actor degraded, and the fix was to point at a different endpoint on the same balance rather than to rebuild anything.

* You keep an Associates tag only if you still earn commissions, which is separate from where your data comes from.

The Creators API is Amazon's official successor and the natural move for a pure affiliate who only needs prices and ratings inside Amazon's blessed pipeline. Expect real work: OAuth 2.0 client credentials, a new endpoint and a new request shape, not a config flip. And it inherits the same limit: no review text.

When should you not use Monid?

You are a pure affiliate who only needs prices and ratings. The Creators API is free under affiliate terms and official. Free and official beats metered when the fields overlap.

You need a contractual guarantee on a field being present. Everything above is scraped from public pages, and this guide's own correction is what that risk looks like in practice: an endpoint that worked in July returned empty prices in August, and still billed. A vendor contract with an SLA is a different product, and if a missing price breaks your business, buy that instead.

You need Amazon's own numbers. Sales estimates from any third party are inferred, never Amazon's internal figures, and should be treated as directional.

And the caution about us: across five endpoints measured on 2026-08-12, two billed in a shape their metadata did not describe and one returned mostly empty records at full price. monid inspect is free and tells you what an endpoint claims. Only a run tells you what it delivers. Do one before you wire anything into production, and do another when something that used to work starts looking thin.

Conclusion

The migration itself is smaller than it looks: an auth rewrite and a field remap, because you are reading the same underlying Amazon data. The part worth slowing down for is which endpoint you point at, and that cannot be settled by reading descriptions. The endpoint whose description best matched GetItems is the one that returned no price, and the one filed under search is the one carrying prices on every row.

The real lesson from PA-API is not that Amazon removed something. It is that a data source wired directly into a product becomes a migration project the day it changes. Keep the provider and endpoint as parameters and the same event becomes an edit.

A working migration is four steps and the first two are free: monid inspect the replacements to see fields and prices, run one ASIN and one keyword and diff the output against what you parse today, swap your calls, then add the review text PA-API never gave you. Start at monid.ai.

FAQ

Last updated August 2026.