Amazon Captcha: How AWS WAF Blocks Scrapers (2026)

Type “amazon captcha” into Google and you get two completely different problems wearing the same name. Most articles never tell you that, so people try a fix for one and wonder why it does nothing for the other.

One is the old distorted-text box. “Enter the characters you see below.” You can solve it in two lines of Python. The other is AWS WAF, a token-based wall that runs a silent JavaScript test on your browser before it lets you breathe. That one is genuinely hard.

If your scraper keeps hitting a captcha and nothing you try seems to work, you’re probably mixing these two up. Let’s untangle them.

Amazon serves two different captchas under one name: a readable Robot Check you can solve with the amazoncaptcha Python library in two lines at roughly 90%+ accuracy, and the AWS WAF token challenge that fingerprints your browser before issuing an aws-waf-token cookie. FlyByAPIs handles both server-side, so you send one request and get clean JSON back instead of maintaining a solver that breaks every Chrome release.

We run Amazon extraction at scale through our own Amazon scraping API , so I’ve spent more hours than I’d like staring at both of these walls. Here’s what each one actually is, how scrapers get past them, and the honest point where fighting it stops being worth your time.

Two kinds of amazon captcha, not one

Before any code, get this distinction straight. It saves you days.

They look related because both stop bots. Technically they share almost nothing. The Robot Check is a static image asking you to read letters. AWS WAF never shows a puzzle unless its invisible test already decided you’re suspicious.

Which one you hit depends on the page and the day. Product pages and search results usually throw the Robot Check. AWS-fronted endpoints, and increasingly more of Amazon’s properties, throw the WAF challenge.

Type one: the Robot Check text captcha

This is the friendly one. The “Robot Check” page shows a distorted-text image and an input box, nothing more. No proof-of-work, no fingerprinting, no token. Just letters a human is supposed to read.

And here’s the part nobody mentions: there’s a library built specifically for it. amazoncaptcha is pure Python, Pillow-based, and trained only on Amazon’s font. No pytesseract, no cloud OCR service, no executables to install.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

from amazoncaptcha import AmazonCaptcha

# Grab the captcha image URL from the Robot Check page,
# then hand it straight to the solver.
captcha = AmazonCaptcha.fromlink(
    "https://images-na.ssl-images-amazon.com/captcha/abcd/Captcha_xyz.jpg"
)
solution = captcha.solve()

print(solution)  # -> "KRJMHG"

That’s the whole thing. Two real lines. Accuracy sits around 90%+ on the live captcha, which is plenty when a retry costs you nothing.

It’s popular enough that people ported it. There’s a Go implementation reporting 99.55% across 15,386 captcha images, and a Rust port floating around too. The technique is solid and well-trodden.

So if the Robot Check is this easy, why does everyone complain about Amazon’s anti-bot defenses? Because solving the image was never the hard part. Getting served fewer of them is. And the system that decides whether you even reach a page is Type 2.

Type two: AWS WAF and the aws-waf-token

Now the hard one. AWS WAF (Web Application Firewall) protects a huge slice of the internet, and its captcha is nothing like a distorted image. It’s a token system.

When you first hit a protected endpoint, WAF runs a challenge in the background. Your browser executes a chunk of obfuscated JavaScript: a small proof-of-work plus an active interrogation of the browser itself. It checks for automation flags, inconsistent browser settings, and a WebGL fingerprint.

Pass that silent test and you get an encrypted cookie named aws-waf-token. According to AWS’s own docs , the token fingerprints your session with the timestamp of your last successful silent challenge, the timestamp of your last CAPTCHA pass, and a pile of non-unique client signals about how human you look.

That’s the difference between the WAF Challenge action and the CAPTCHA action. Challenge is silent and only interrupts you if it fails. CAPTCHA is the visible puzzle, the fallback. Both end with the same cookie in your jar.

The token has an immunity time you don’t control as a scraper. It’s configurable per site. Some run a few minutes, and people have measured others holding valid for around four days. Inside that window, a request carrying the token sails through. Outside it, you’re challenged again.

The clever, frustrating part: AWS deliberately obfuscates the token generation and rotates it. There’s no stable algorithm to copy. What worked last month can quietly break this month.

People do reverse-engineer it. There’s an open-source AWS WAF solver in Go and Python that extracts the challenge’s gokuProps, deobfuscates the script, and produces a valid token. It works until AWS ships a change, then it doesn’t. Keeping a solver alive is exactly the chore FlyByAPIs folded into our Amazon API that handles the captcha for you , so the breakage is our problem, not yours.

Why your scraper trips the silent challenge before you see anything

Here’s something that catches people out. You haven’t even reached a captcha yet, and Amazon already flagged you. Why? Your HTTP client gave you away at the handshake.

Every TLS connection has a fingerprint, usually summarized as a JA3 hash. Real Chrome produces one well-known hash. Python’s requests and aiohttp produce a completely different one that anti-bot systems have catalogued for years. You’re identified before a single byte of HTML moves.

This is why curl or plain requests bounce off Amazon while a browser walks in. The fix is curl_cffi , which wraps a curl build that impersonates a real browser’s TLS and HTTP/2 fingerprint.

1
2
3
4
5
6
7
8
9

from curl_cffi import requests

# impersonate="chrome" matches Chrome's TLS (JA3) and HTTP/2 fingerprint,
# so the request doesn't scream "Python" at the handshake.
r = requests.get(
    "https://www.amazon.com/dp/B0DGJ7HYG1",
    impersonate="chrome",
)
print(r.status_code)

In our own testing, the gap is night and day: aiohttp gets blocked on endpoints where curl_cffi with Chrome impersonation walks straight through. Same request, same proxy, different fingerprint, different outcome.

There’s a second layer underneath the fingerprint: IP reputation. Amazon scores the IP. Data-center ranges are treated with suspicion, residential ones less so, and a country-matched IP looks the most normal of all. Throttle politely from a clean IP and you’ll see far fewer challenges than you would hammering from a flagged subnet.

One small mercy worth knowing: Amazon mostly throttles rather than permanently bans. Intermittent 503s tend to self-heal within seconds. If you’re getting blocked hard and permanently, your fingerprint or IP is the problem, not your request rate. It’s the kind of tuning a managed Amazon data extraction API does for you, balancing rate against IP reputation so you never see a 503 in the first place.

How to adapt without fighting the arms race

So you’ve got a real fingerprint and a clean IP. You still need to clear the WAF challenge, which means executing JavaScript, which means a real browser. The trick is not paying that cost on every single request.

The pattern that works is hybrid token harvesting. Use a browser to solve the challenge once, grab the aws-waf-token cookie, then hand it to a fast HTTP client for the bulk of your requests. Pay the browser tax once, not a thousand times.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from playwright.sync_api import sync_playwright
from curl_cffi import requests

# 1. Browser solves the silent challenge and earns the token.
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://www.amazon.com/dp/B0DGJ7HYG1")
    cookies = {c["name"]: c["value"] for c in page.context.cookies()}
    browser.close()

# 2. Reuse the harvested cookie with a browser-matched fingerprint.
#    Amazon cookies aren't tied to your IP, so you can rotate proxies freely.
r = requests.get(
    "https://www.amazon.com/dp/B0DGJ7HYG1",
    cookies=cookies,
    impersonate="chrome",
)
print(r.status_code)

The reason this works: Amazon’s cookies generally aren’t bound to a specific IP or TLS fingerprint, so one harvested token can ride across rotating proxies until it expires. Refresh it when the immunity window runs out, and keep going.

For the browser half, don’t reach for vanilla Selenium. Use tooling built to hide automation tells:

nodriver , from the author of undetected-chromedriver, patches detection vectors at the driver level. Pair it with residential proxies and human-like pacing, and you’ll clear the silent challenge most of the time. If maintaining all of that sounds like a second job, that’s the whole reason we let people scrape Amazon without solving captchas at all.

Then there are paid solvers like CapSolver and 2Captcha that handle the WAF puzzle for you. They work, they cost real money per solve, and they break when the challenge changes. Useful as a fallback, painful as a foundation.

Stack all of this and you can scrape Amazon. I want to be honest about what you just signed up for, though.

Is bypassing the captcha even legal?

Quick, honest aside, because it matters. Scraping publicly visible data is broadly lawful in many places, and courts have leaned that way in several cases. That’s not the whole story.

Amazon’s Terms of Service explicitly forbid automated access. Circumventing an access control is a different legal question from reading a public page, and it varies by country. None of this article is legal advice.

The compliant path is also usually the cheaper one once you count your own hours. It’s also why teams that need to bypass Amazon’s captcha with a managed API tend to sleep better: the access question lives with a vendor whose entire job is staying inside the lines. Which brings me to the part where I stopped fighting walls for a living.

When to stop scraping and call an API

Look back at everything above. Fingerprint matching that ages out every Chrome release. A token format AWS rotates on purpose. Solvers that break. Proxy pools to maintain, IP reputation to babysit, browsers to keep undetected.

Each piece is solvable. Together they’re a permanent part-time job. You’re not building a product anymore, you’re running anti-bot infrastructure, and Amazon’s whole job is to make that harder than yours.

That’s the actual pitch for the FlyByAPIs Amazon scraping API : someone else runs the arms race. You send an ASIN, structured JSON comes back. The captcha, the token, the proxies, the fingerprint, all of it lives on our side.

One detail I genuinely care about: the FlyByAPIs country-pinned Amazon data API routes a marketplace=de request through a German IP, so the price and buy box you get match what a shopper in Berlin actually sees. Scrape Amazon.de from a US data center and you get the foreign-visitor version of the page, which quietly corrupts your pricing data.

Billing matters too. We charge per request, so one search call returning 30 to 50 products costs the same as one product lookup. Vendors that bill per record or per result charge you for every row in that response, which gets expensive fast on search workloads. If you want the full breakdown, our Amazon product data API pricing is public.

The same wall, by the way, shows up everywhere data lives behind a firewall. We built the same anti-bot handling into a Google Search API , a Google Maps data API , a Crunchbase scraper , a jobs search API , and a translation API , because the captcha problem is never really about the captcha. It’s about not wanting to maintain six versions of this article in code.

The short version

Two walls, one name. The Robot Check is a readable image you can solve in two lines with the right library. AWS WAF is a token system that interrogates your browser, hands out an aws-waf-token, and rotates the rules whenever it feels like it.

If you want to learn how anti-bot systems work, build the scraper. It’s a genuinely good education, and our Python web scraping guide and Amazon scraping walkthrough will get you started. If you just want the data, the maths usually favors letting someone else maintain the fight.

I spent years on the wall side of this. Building the API was, mostly, me getting tired of patching the same five things every month. If that sounds familiar, you know which side to pick.

What are you scraping Amazon for? If it’s pricing, our Amazon price tracker tutorial shows the whole thing end to end without a single captcha in sight.

Oriol.