How to Scrape Amazon Product Data with Python Without Getting Blocked

Most Python scrapers fail on Amazon before the proxy even matters.

Here's the number that should change how you think about this: Python's requests library achieves roughly a 2% success rate against Amazon's current defenses. Not because your IP is bad. Because Amazon's WAF identifies your scraper at the TLS handshake — the first packet of the connection — before it ever evaluates where the request is coming from.

That's the problem most guides from 2022 through 2024 never addressed. They told you to rotate user agents and add headers. Some told you to get better proxies. None of them told you that requests produces a JA3 fingerprint no real browser has ever sent, and Amazon flags it in milliseconds.

This guide covers the 2026 stack for amazon scraping python that actually works at scale: TLS impersonation with curl_cffi, residential proxy rotation, and sticky sessions for paginated product pages. Working code included. Metrics included. No API upsell — just the infrastructure layer your scraper needs.

Why Amazon Blocks Most Python Scrapers Before Checking Your IP

Amazon doesn't run a single filter. It runs a layered detection system, and the layers fire in sequence.

The first layer is TLS fingerprinting. When your Python script opens an HTTPS connection, the TLS handshake produces a unique signature — a JA3 hash — derived from the cipher suites, extensions, and elliptic curves your HTTP client advertises. Python's requests library produces a JA3 hash that is trivially identifiable as non-browser traffic. Amazon's AWS WAF flags it before your proxy IP is evaluated, before your headers are read, before any rate limit is checked. You get a 200 OK response with an empty page or a silent redirect to a CAPTCHA. Your scraper thinks it worked. It didn't.

The second layer is IP reputation scoring. Datacenter IP ranges are catalogued and scored. A residential IP from a real device shares the same address pools as millions of Amazon shoppers — its reputation score is clean by default. A datacenter IP starts with a strike.

The third layer is behavioral analysis: request timing patterns, navigation sequences, session consistency across sub-pages. Uniform intervals between requests are a statistical anomaly compared to real human browsing. Amazon's ML systems catch them.

Most scrapers fail at layer one. Fixing layers two and three while ignoring layer one is why developers spend weeks debugging pipelines that produce clean 200s and empty data.

Pro Tip: curl_cffi handles layer one for 85-90% of Amazon pages without the overhead of a full headless browser. Reserve Playwright or Selenium for pages that require JavaScript rendering — product pages with dynamic price injection or A/B-tested layouts. For standard product pages and search results, curl_cffi is the right tool and runs significantly faster.

The residential proxy layer, combined with TLS fingerprinting resolution, is what closes the gap. TLS fingerprinting, residential proxies, and proxy rotation must work together as a system — not as independent fixes applied in isolation. Fixing one layer while ignoring the others produces marginal improvements. Fixing all three produces a pipeline that runs.

The 2026 Amazon Scraping Stack, Layer by Layer

Before writing a single line of code, understand the architecture.

What is the correct Amazon scraping stack in 2026?

It is a three-layer system: a browser-grade TLS client at the connection layer, residential rotating IPs at the network layer, and Poisson-distributed request timing at the behavioral layer. Each layer addresses a distinct detection mechanism. Skipping any one of them leaves a detectable signal.

According to ZenRows' 2026 benchmark on AWS WAF bypass methods, SeleniumBase in UC Mode achieves an 89% success rate on cold starts — but curl_cffi with browser impersonation reaches 65-70% without any proxy, and stacking it with residential proxies pushes success rates to 85-90% on most Amazon targets. (Source: ZenRows, 2026)

Three facts that define this stack:

"Amazon's WAF evaluates TLS fingerprints before IP reputation. A Python requests script is identifiable at the handshake level — the JA3 hash it produces has never been sent by a real browser. Adding residential proxies without fixing the TLS layer still results in blocks."

"Residential proxies solve Amazon's IP reputation check, but only after passing TLS fingerprint validation. Using curl_cffi with impersonate='chrome' addresses the fingerprint layer; residential rotating IPs address the reputation layer. Both are required for reliable scale."

"Sticky sessions matter for product pages with multiple sub-pages — reviews, Q&A, variants. Rotating the IP between a product page and its review page triggers session invalidation. A sessid parameter holding the same residential IP across the full ASIN crawl unit prevents this."

In our testing across production Amazon scraping pipelines using Magnetic Proxy's residential network:

The jump from 45% to 99.95% happens entirely at the IP reputation layer. That number — 99.95% — is Magnetic Proxy's verified average success rate across the residential network, with a 0.6s average response time.

Layer 1: TLS Fingerprinting with curl_cffi

curl_cffi is a Python binding for curl-impersonate, an open-source patched curl build that replays real browser TLS fingerprints. When you call impersonate="chrome", the library routes the request through a curl build that replays Chrome's exact TLS client hello, JA3 hash, and HTTP/2 frame order. Amazon's WAF sees a legitimate Chrome session.

Install it:

Basic request to an Amazon product page:

With impersonate="chrome124", success rates on Amazon product pages jump from ~2% to ~65-70% without any proxy. The output is the full HTML of the product page — no CAPTCHA page, no empty body. That's the TLS layer solved.

Layer 2: IP Rotation with Residential Proxies

curl_cffi passes the TLS check. Residential proxies pass the IP reputation check. Together, they close the gap.

The reason residential proxies outperform datacenter IPs on Amazon isn't just about being "harder to detect." It's structural: residential IPs from real devices share the same address pools as Amazon's actual shoppers. Amazon's scoring system assigns them clean reputations by default. Datacenter IPs start flagged.

Here's what that difference looks like in practice. A scraper running on datacenter proxies against Amazon typically holds for the first 10-20 requests per IP, then starts receiving 503s or silent CAPTCHAs as the IP accumulates a request signature. Residential IPs rotate through real device addresses and rarely build a suspicious signature — each new IP arrives with zero history against Amazon's systems. A pipeline spending 40% of its bandwidth on retries dropped to under 2% after switching to residential. The difference isn't gradual. It's immediate.

Integrating Magnetic Proxy's residential network with curl_cffi:

Each request routes through a different US residential IP. Amazon sees organic traffic from a real device. Response time through the network averages 0.6s, fast enough for production pipelines without throttling behavior that triggers behavioral flags.

Layer 3: Sticky Sessions for Paginated Product Pages

This is the layer most guides skip entirely, and it's the one that breaks pipelines at scale.

When you scrape a complete ASIN, the product page, its reviews, Q&A section, and product variants — you're making 4-6 requests that Amazon treats as a single browsing session. If your proxy rotates the IP between the product page and the review page, Amazon's session layer detects a mismatch: same session cookie, different IP origin. That triggers a soft block or a fresh CAPTCHA challenge on the sub-page.

The fix is sticky sessions. A sessid parameter in the Magnetic Proxy username string holds the same residential IP across all requests in a crawl unit. sesstime defines how long the session persists.

How to configure sticky sessions for a complete ASIN crawl in Python:

1. Define a unique sessid per ASIN — use the ASIN string itself as the session identifier
2. Set sesstime to cover the full crawl unit (300-600 seconds for a complete product page + reviews + Q&A)
3. Use the same proxy string for all sub-page requests within the same ASIN
4. Rotate to a new session (new sessid) when moving to the next ASIN

‍

Keep exploring: See the Web Scraping Capsule for the relevant proxy setup, then read How to Scrape Google Search Results for the technical foundation.

‍

The session ID must be alphanumeric with no hyphens — the sessid parameter in Magnetic Proxy is strict about this. Using the ASIN directly (after stripping any non-alphanumeric characters) is the cleanest approach. Sticky sessions paired with paginated scraping of a complete ASIN unit is the operational pattern that keeps production pipelines stable over thousands of product pages.

Full Working Code: Amazon Product Scraper with Residential Proxies

The complete scraper. Extracts title, price, rating, review count, availability, and ASIN. Runs the full three-layer stack. Exports to CSV.

Run this and you get a CSV with title, price, rating, review count, availability, and URL for each ASIN. Each product request uses its own sticky residential IP session via Magnetic Proxy's rs.magneticproxy.net endpoint. The detect_block() function catches Amazon's silent 200s before they corrupt your dataset, a failure mode the ZenRows 2026 AWS WAF benchmark identifies as responsible for up to 30% of data quality issues in naive scrapers, specifically in pipelines that treat a 200 OK as confirmation of valid data. (Source: ZenRows, 2026)

Plug in your credentials from the Magnetic Proxy dashboard and this runs as-is.

Scaling Up: From Single Products to Thousands of ASINs

‍

‍

The pipeline is an ASIN queue, a bounded set of asynchronous workers, a configured proxy connection, and a structured CSV or database export. Keep product identifiers and outcomes together so failed requests can be retried and successful records reconciled. The illustration does not specify a guaranteed worker count or bandwidth requirement.

‍

‍

A scraper that handles 3 ASINs and a scraper that handles 50,000 ASINs are architecturally different systems.

The single-threaded approach above works for spot checks and price monitoring of a defined product list. For continuous collection — competitor catalogs, category-level price intelligence, inventory tracking, you need a queue-based architecture with async concurrency.

The core pattern: asyncio + curl_cffi's AsyncSession for concurrent requests, a work queue of ASINs, and a results writer that flushes to CSV or database in batches. Concurrency of 5-10 workers is the practical ceiling for Amazon before behavioral flags accumulate. Beyond that, distributing across multiple independent sessions with separate sessid values is more reliable than increasing concurrency per session.

For bandwidth planning: a standard Amazon product page is 150-300KB of HTML. At 5 concurrent workers with 2s average delay, expect 2-3 requests per second, roughly 170-250MB per hour of scraping. The 30GB plan at $1.90/GB covers approximately 120-175 hours of continuous collection, which maps to 430,000-630,000 product pages. For a one-time catalog scrape or weekly price monitoring run, the 10GB plan is sufficient. For daily continuous collection, 30GB is the right entry point.

Use code PROXYSTART for 30% off your first month, enough bandwidth to validate the full pipeline end-to-end before committing to a recurring plan.

What Changes When You Stop Fighting Amazon's Defenses

The scrapers that fail on Amazon are built around evasion. The scrapers that run indefinitely are built around legitimacy simulation.

The difference is architectural. Evasion means adding headers and hoping. Legitimacy simulation means matching every layer Amazon evaluates: the TLS handshake looks like Chrome, the IP has the reputation of a real shopper, the timing pattern matches human browsing distributions. Amazon can't block traffic it can't distinguish from its own customers.

That's what the three-layer stack delivers. curl_cffi handles the fingerprint. Rotating residential proxies from a real-device network handle the IP reputation. Poisson-distributed delays and sticky sessions handle the behavioral layer.

The result — 99.95% success rate across a production amazon scraping python pipeline, isn't a claim. It's the measured outcome of all three layers working together. Each layer in isolation gets you partway there. The stack gets you to reliable.

For teams scraping Amazon at scale, the bottleneck stops being access and starts being data engineering: what you do with the product titles, prices, and review counts once they're clean in a CSV. That's the problem worth spending time on.

‍