Build an Amazon Price Tracker in Python (the Honest Way)

I thought I'd found the cheapest PlayStation 5 on the internet.

My price tracker printed $74.00 next to a PS5, but if it sounds too good to be true online, it almost always is. That $74 wasn't the console. It was the scraper grabbing the wrong element, and it's exactly the kind of silent bug that makes most "Amazon price tracker" tutorials quietly useless.

So instead of just publishing fifty lines of Python and calling it done, which is what nearly every guide does, I tested the thing properly. I ran it against Amazon at volume, measured exactly what gets blocked and what doesn't, and fixed the bugs the tutorials never mention. The results were genuinely surprising: a bare scraper hit a product page 150 times without a single block, but got shut down on the very first request to a search page.

This guide is the working tracker plus everything that testing turned up, including a Selenium trick worth knowing even if you've built scrapers before: it drives a real Chrome window, visually, so you watch the page load and scrape in real time.

Will Amazon actually block you?

Every tutorial warns you that Amazon will block your scraper instantly. So I tested it, and the results genuinely confused me.

I pointed a bare, no-frills scraper at a PlayStation 5 product page and just let it hammer away. One request, two, ten, fifty, I kept waiting for the wall. It never came. The thing fired 150 requests at the same page and every single one came back "ok." I couldn't believe how open-gate it was.

It was. Product pages, it turns out, barely care. Then I pointed the same scraper at a search results page, and it died on the very first request. Not the tenth, not the fiftieth. The first. A 503 straight away.

Search results are where the real data-harvesting happens, so that's where Amazon spends its defenses. Individual product pages? Wide open.

Here's what I tried and what happened:

• Product page, bare scraper: 150 requests, zero blocks

• Search page, bare scraper: blocked on request #1 (503)

• Search page, better headers: still blocked on request #1

• Search page, headers + residential proxy: still blocked on request #1

• Search page, real browser: worked, 16 results

• Search page, browser + US proxy: worked, 22 results

The part that surprised me most: throwing a residential proxy at the search page didn't help at all. Still blocked, first request. The block was never about my IP address, it was about the fact that I wasn't a real browser. The moment I loaded the same search page in an actual browser instead of a raw script, it worked:

Building the tracker

Let's build the thing. The whole tracker is about 50 lines of Python. You need Python 3 and Google Chrome installed, then one command for the libraries:

pip install selenium requests matplotlib

Pointing it at a product

Every Amazon product has an ID called an ASIN, the 10-character code in the URL right after /dp/. For example, in amazon.com/dp/B0F1J12R6N, the ASIN is B0F1J12R6N. That's all the tracker needs to find a product.

Why requests isn't enough

The obvious way to scrape a page is Python's requests library: one line, grab the HTML, done. And for a product page, it even returns a 200 OK. But here's the trap I fell into: a 200 doesn't mean you got the data. Amazon builds the price into the page with JavaScript, and requests doesn't run JavaScript. So you get a page back, but the price isn't in it.

That's why this tracker uses Selenium instead. Selenium drives a real Chrome browser: it actually opens the page, runs the JavaScript, and lets you read the fully rendered result. The first time you run it, Chrome opens on its own with a banner saying "Chrome is being controlled by automated test software," and you watch it work in real time.

Scraping the price (and the bug everyone ships)

This is where most tutorials quietly break. The common approach grabs the .a-price element and reads its text. The problem: Amazon puts the price in that element twice, once visible, once for screen readers, so you get a garbled $449.00$449.00 instead of a clean number.

The fix is to target the clean, single copy of the price inside the buy box and read it carefully, checking the main buy-box price first so you don't accidentally grab an accessory's price, which is exactly how I ended up with that "$74 PS5." The exact selectors are in the code on GitHub.

Once it targets the right element, the price comes back clean:

Storing the history and charting it

A price tracker is only useful if it remembers. The script saves each reading to a file, keyed by product, storing the price as an actual number plus its currency, not a "$54.00" string. That matters: numbers you can chart, compare, and find the lowest of; strings you can't. Left alone, the script checks once and stops; add a loop option and it re-checks on a schedule, building history over time that a second small script turns into a price-over-time chart.

The bug that almost cost me: you might be scraping the wrong country

Remember that $74 PlayStation? That was the first sign something was off. The second was worse, because it was harder to spot.

When I first ran the tracker without a proxy, Amazon didn't just give me odd prices, for some products it gave me no real price at all, just a "this item can't be shipped to your location" notice. The tracker had nothing useful to record.

So I routed it through a proxy to look like a US shopper. The price came back in euros. At first I assumed the proxy hadn't worked at all. Then I noticed the page said "Deliver to Ireland," and it clicked: the proxy worked fine, it had just dropped me onto an Irish IP. Right idea, wrong country.

The fix is a residential proxy pinned to the country you actually care about. Once I locked mine to the US, the tracker pulled the correct price, $54.00, in dollars, every time.

And that country-pinning isn't a nice-to-have, it's the whole point. Say you're tracking competitor prices to decide what to charge in a given market. Those numbers only mean something if they're the prices that market actually sees. The same product might be $449 in the US and €499 in Ireland. If your scraper quietly hands back the Irish price, you're making decisions for one market based on another market's data, and because it looks valid, nobody catches it.

So a proxy here isn't about sneaking past blocks, my testing showed product pages barely block anyway. It's about making sure the data you collect is the right data.

If you want price data pinned to a specific country, FlashProxy's residential proxies let you target any location, so you're always collecting the prices that market actually sees.

So… should this have been harder?

Here's my honest takeaway: if you ever need to scrape prices off a webpage, you don't have to read a hundred blogs, watch a pile of YouTube videos, or keep nagging an AI until it finally gets it right. You can just do it yourself. It's extremely easy, and honestly, it's almost worrying how easy it is.

Before I started, I assumed this would be hard. I was genuinely nervous running the early tests without a proxy connected, I figured I'd get blocked forever, or rate-limited into oblivion. I expected consequences.

Nothing happened. Literally nothing. 150 requests at a product page, no proxy, no blocks, no ban, no angry email. The wall I was bracing for mostly wasn't there, and the one place it was (search pages), a real browser walked right through it.

So if the only thing stopping you from building one of these was the assumption that it's hard or risky: it isn't. Build it. Just keep it reasonable, track public prices, don't hammer the site, and respect their terms. But the fear? Mostly in your head, same as it was in mine.

The full code

The complete project, the tracker, the proxy helper, the charting, and the test scripts, is open source: amazon-price-tracker-python on GitHub. Clone it and run, or read through exactly how it works.