How to scrape amazon product data with mobile proxies (2026)

You point a scraper at amazon, pull a handful of product pages, and somewhere around the fiftieth request it falls apart. Empty pages, a robot check, prices that never load. The code is fine. amazon just decided your traffic is not a shopper. I run a hardware proxy farm in Singapore, real phones on real Singtel, M1, and StarHub sims, so I watch what survives against a target like this and what gets burned in the first hour. Here is the honest version.

Why amazon blocks so hard

amazon is not one wall, it is a stack of them, and they all watch at once.

Rate limits come first. amazon tracks how fast one ip asks for things, and a real shopper is slow. They open a page, read, scroll, maybe come back in a minute. Your scraper fires thirty pages in twenty seconds and that pace alone marks you.

Then there is ip reputation. A datacenter ip lives in a hosting range that every anti bot system has mapped by asn, not just by address. Rotating to the next datacenter ip in the same block buys you nothing, because the whole neighbourhood is already scored before your request lands.

Behavioral detection is the layer most people miss. amazon watches the shape of your traffic: requests on a perfectly even rhythm, no images loading, headers that do not match a real browser. Each signal is tiny. Stacked together they read as automation.

And when you trip the line you get the robot check and the captcha. Once it fires on an ip, that ip is done for the session. You can pay a solver, but a fresh challenge is usually waiting right behind it.

There is also the regional pricing wall. amazon serves different prices, availability, and even a different marketplace depending on where it thinks you are. The location your ip reports changes the numbers you get back.

Why a carrier ip looks different

Here is the shift that changes the math. A carrier ip looks like a real person shopping on a phone, and that is exactly the traffic amazon expects, because a huge share of amazon shopping happens on a handset.

It works because of carrier grade nat. On a mobile network one public ip is shared by a crowd of real subscribers at the same time. Blocking that ip means blocking the carrier’s own paying customers, so amazon is far more careful about it. In our case that crowd is real people on a Singapore sim on Singtel, M1, or StarHub.

Pace and randomize

A believable ip is only half the job. The other half is behaving like the shopper that ip is pretending to be. Put a real gap between page loads, vary that gap, and never fire on a fixed metronome. A slow human looking trickle survives where a fast even burst dies.

Keep a sane per ip rate

A mobile proxy is one phone with one radio. Push forty parallel requests through it and the handset chokes, the carrier throttles, and it looks exactly like amazon blocking you when really you overloaded one device. Keep it to a handful of requests per ip. If you need more throughput you need more phones, not more threads through one phone.

One sticky session per worker

Each scraping worker should hold one ip for the length of its run, so the whole run looks like one shopper browsing for a while. That is what a sticky session gives you. If your egress ip flips mid run, amazon sees a person who teleported across the planet between two clicks, and that is a far louder flag than slow scraping ever was.

Let the carrier rotate between runs

On a real mobile network the ip changes on its own as the device moves between towers and the carrier reassigns addresses. Lean into that natural schedule to spread load across ips over time, so no single address ever looks busy, instead of slamming one ip on a tight loop.

Handle the robot check gracefully

When you hit a captcha or the robot check page, do not retry the same ip harder. Back off, rotate to a fresh session, and come back slower. Treat that page as a signal that you went too fast, not as an error to brute force. The scrapers that survive are the ones that ease off the moment amazon pushes back.

Geo accurate pricing

This is where a Singapore ip pays off. A Singapore carrier ip sees the Singapore marketplace, prices in the local currency, local availability, and local delivery estimates. If you are tracking prices for the Singapore market, that locale accurate data is the whole point. A datacenter ip in another country quietly hands you the wrong marketplace and you would not notice until the numbers are already wrong.

Parse responsibly

Cache what you pull so you are not requesting the same product page ten times an hour. Re scrape on a schedule that matches how often prices actually change, not as fast as your machine can loop. Hammering a target does not get you better data, it just gets your ips burned faster.

The honest part

Scraping amazon is against amazon’s terms of service. Everything above is the technical reality of why a real mobile ip survives where a datacenter ip dies, not a promise that you should run it. If you are doing this at production scale, for a product or a business, use the official product advertising api or a licensed data source. They are built for this, they are stable, and they will not vanish the day amazon tightens a screw.

Mobile proxies earn their place in the in between work: small scale price checks, verifying how a listing looks from a real Singapore connection, confirming local pricing the way a customer on a phone would see it. For that, a real carrier ip is the right tool and the full api is overkill.

Try it on real SG mobile ips

If you want to test how amazon treats a real Singapore phone, I run the farm myself: real phones, real Singtel, M1, and StarHub sims, sticky sessions so one worker keeps one identity through a run, and dns that routes through the tunnel so your lookups do not leak your real location. There is a free trial on the home page, and code YT30 takes thirty percent off your first month. Point your scraper at a real SG mobile ip and see where the robot checks stop showing up before you commit.

Get new guides and videos first — join the Telegram channel.