How to Scrape Amazon: A Python Guide (Tested)

Amazon is the most-scraped site on the consumer web and one of the most defended. Prices, ratings, review counts, and rank are the raw material for repricing tools, market research, and arbitrage. This guide builds a real Python scraper, tests it against a live listing, and shows exactly where DIY scraping holds up and where it breaks. I ran the code in June 2026 and pasted the real output below, including the part that did not work.

Can you scrape Amazon, and is it legal?

You can fetch a public Amazon product page with a script, and the legality depends on how you do it and what you take. The technical part is easy: a single product page returns HTTP 200 to a plain request, as my test below shows. The legal part has two layers worth separating.

On US computer-access law, scraping pages anyone can load without logging in sits on the safer side. In hiQ Labs v. LinkedIn, the Ninth Circuit held that scraping public profiles does not violate the Computer Fraud and Abuse Act, and the Supreme Court’s Van Buren decision narrowed the CFAA to something close to traditional hacking. So reading a public listing page with a bot is not, by itself, a federal computer crime.

Contract law is the live risk. Amazon’s Conditions of Use prohibit data mining, robots, and other automated data-gathering tools, and using the site means accepting those terms. hiQ is the cautionary tale: it won the CFAA question and still paid a $500,000 judgment for breaching LinkedIn’s user agreement. Two rules keep you on the lower-risk path. Stay on public pages and never script a logged-in account. Avoid collecting personal data, which pulls in the GDPR in Europe. I am a tester, not a lawyer, so get advice before any commercial scrape. My is web scraping legal pillar covers the full picture.

What data can you extract from an Amazon product page?

A product page carries most of the commercially useful fields, but they are not equally easy to reach. Some sit in static HTML that any parser reads on the first request. Others live in the buybox, which Amazon renders based on your session and delivery location, so a cold request often gets a 200 with those fields missing.

The pattern to internalize: the descriptive, mostly-static fields parse fine, and the transactional fields (price, stock) are the ones Amazon protects. That ordering matters because price is usually the whole point of an Amazon scrape, and it is the first thing a naive scraper loses.

Method 1: scrape Amazon with requests and BeautifulSoup

A requests GET with a real browser User-Agent plus BeautifulSoup parsing is the simplest scraper, and it gets you partway. Here is the exact code I ran against a live Amazon listing (the Echo Dot, ASIN B09B8V1LZ3):

import requests
from bs4 import BeautifulSoup

HEADERS = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/126.0.0.0 Safari/537.36"
    ),
    "Accept-Language": "en-US,en;q=0.9",
}

url = "https://www.amazon.com/dp/B09B8V1LZ3"
resp = requests.get(url, headers=HEADERS, timeout=30)
print("STATUS:", resp.status_code)

soup = BeautifulSoup(resp.text, "html.parser")

def text_or_none(selector):
    el = soup.select_one(selector)
    return el.get_text(strip=True) if el else None

title = text_or_none("#productTitle")
price = text_or_none("span.a-price span.a-offscreen")
popover = soup.select_one("#acrPopover")
rating = popover.get("title") if popover else None
reviews = text_or_none("#acrCustomerReviewText")

print("title:", title)
print("price:", price)
print("rating:", rating)
print("reviews:", reviews)

The real output:

STATUS: 200
title: Amazon Echo Dot (newest model) - Vibrant sounding speaker, Designed for Alexa+, Great for bedrooms, dining rooms and offices, Charcoal
price: None
rating: 4.7 out of 5 stars
reviews: (193,685)

Read that output carefully, because it is the honest result. The request succeeded (200), and the title, rating, and review count all parsed. The price came back None. That is not a broken selector. Amazon gates the buybox behind a delivery-location session, so a first, cookie-less request renders the page without a resolvable price block. I confirmed the availability element on the same page read “This item cannot be shipped to your selected delivery location,” which is the same gate showing up a different way.

So Method 1 is genuinely useful for catalog data (title, rating, review volume, features) and genuinely weak for the transactional fields. To get the price this way you would establish a session with a location cookie (Amazon sets one when you pick a ZIP), and even then a static request cannot run the JavaScript that hydrates parts of the page. For one product that is solvable with patience. The trouble starts when you scale.

How does Amazon block scrapers at scale?

Amazon’s defenses ramp up fast once one IP makes repeated requests, and a single machine running a loop hits them within a handful of pages. The single product fetch above worked. A thousand of them from the same address will not. These are the layers you run into:

Two of these are subtle and bite even careful scrapers. The empty-price gate looks like success (200) but yields no price, so a naive crawler logs thousands of “successful” rows with the most important column blank. Layout rotation means Amazon serves several page templates, so a selector that works in one test returns None in production for a slice of requests. Hardcoding one selector and trusting a 200 status is how Amazon scrapers silently rot. The general playbook for surviving these defenses is in my scraping without getting blocked guide; the rest of this article is the Amazon-specific fix.

Method 2: scrape Amazon with a scraper API

A scraper API solves the two hard problems at once. It renders JavaScript through a real browser and routes the request through a rotating residential IP, so the price block resolves and you avoid blocks. You hand it the Amazon URL and get the data back instead of fighting cookies and CAPTCHAs yourself.

ChocoData is the service I use for this category. It exposes a universal endpoint (one URL for any site) plus 453 dedicated endpoints for common targets. Amazon does not have its own named dedicated endpoint in the docs, so the correct route is the universal endpoint with the full product URL, which is what that endpoint is built for. Here is the request shape, swapping the raw requests.get for the API:

import requests

API_KEY = "cd_live_YOUR_KEY"  # free tier: 1,000 requests/month, no card
target = "https://www.amazon.com/dp/B09B8V1LZ3"

endpoint = "https://api.chocodata.com/api/v1/universal/get"
params = {
    "api_key": API_KEY,
    "url": target,
    "parse": "html",   # get rendered HTML back, then parse as in Method 1
    "country": "us",   # US residential IP so pricing/availability resolve
}

resp = requests.get(endpoint, params=params, timeout=90)
print("STATUS:", resp.status_code)
# The rendered page comes back in the JSON payload; parse the same selectors
# as Method 1, but now the buybox is hydrated, so span.a-price .a-offscreen resolves.

The difference from Method 1 is what happens behind that one call. ChocoData fetches through a country-matched residential IP that rotates automatically and retries through a fresh IP when a block appears, and it can run optional JavaScript rendering for the dynamic parts of the page. The country=us parameter is the lever that makes the price resolve, because it gives Amazon a US delivery context instead of the unknown location my cold request had. Billing applies only to successful (2xx) responses at 5 credits each, so the empty-200 problem from Method 1 does not quietly drain your budget.

I did not paste live API output here because that requires a paid key, and I will not fake numbers. The endpoint path, parameters, free-tier limits, and billing model above come from the ChocoData docs. The honest claim is narrow: the universal endpoint takes a URL and returns the rendered page, which removes the two specific failures (empty price, IP blocks) I reproduced in Method 1.

Should you scrape Amazon yourself or use an API?

Use Method 1 for a handful of products and catalog fields; use a scraper API the moment you need price, stock, or volume. The decision comes down to which fields you need and how many pages you are pulling.

My honest take from the test: DIY scraping of Amazon is fine as a learning exercise and for descriptive data, and it falls short for the commercial fields right when a project gets serious. If you only need a product’s title and rating, Method 1 is enough and free. If you need accurate prices across many ASINs without babysitting blocks, the scraper API is the route that actually returns the data.

To go deeper on the building blocks, see the Python web scraping guide for the language fundamentals, BeautifulSoup for parsing, and Scrapy if you are crawling many pages and want a framework. The web scraping pillar ties the whole workflow together.