Amazon Reviews Scraper
Pricing
Pay per event
Scrape the top customer reviews from an Amazon product page by ASIN or URL — rating, title, body, verified-purchase flag, date, and helpful-vote count per review. Pay-Per-Event, no login, no API key.
Pricing
Pay per event
Rating
0.0
(0)
Developer
DevilScrapes
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
1
Monthly active users
a day ago
Last modified
Categories
Share
The start fee is owed on delivery, not on boot. actor-start ($0.20) was
charged immediately after input validation — this Actor's own
pay_per_event.json described it as "charged once when the Actor run begins,
before any fetch". At the 43.3% customer success rate that tripped
UNDER_MAINTENANCE, roughly 17 of every 30 runs paid $0.20 for an empty
dataset — and the failure they paid for was ours: blocking the script
resource type stripped Amazon's client-injected review widget, so the page
looked healthy and the run reported a convincing "0 reviews" (fixed in 0.6).
_StartFee now fires at most once, and only from the first successful row
push. A run where every ASIN is blocked now costs the customer nothing.
Billing a start fee for a run that delivered nothing is the shape that got
vrbo-vacation-rentals-scraper delisted at 17 runs.
Note: the Store listing's own pricing copy still reads "before any fetch" —
pricingInfos is append-only and a bad PUT breaks the whole listing, so that
sentence needs a deliberate pricing-copy pass. The price itself is unchanged.
script-blocking was silently stripping the review widget)UNDER_MAINTENANCE; live build 0.5.3, no undeployed
fix on main). This Actor's own /acts/{id}/runs history stopped at
build 0.5.2 (2026-08-26) — no recent_failures covered the live build, so
reproduced fresh against build=latest (live build 0.5.3) via apify api
cloud runs: 3 single-ASIN reproductions on the shipped input_schema
prefill (asins: ["B0BSHF7WHW"]) succeeded (5 and 10 real review rows), but
a realistic multi-ASIN run (tVT6rxKgkTNIac733, two ASINs a customer
might legitimately batch) FAILED with "0 reviews" for BOTH — including
B0BSHF7WHW and B09B8V1LZ3, both independently confirmed to carry 13 and
8 reviews by the 2026-08-26 Camoufox recon that shipped this Actor's
current architecture. The run log showed a soft-block on attempt 0, a
clean rotation, then total silence (no further warnings) before the
aggregate "no-results" verdict for both ASINs — meaning the rotated
fetch got a real, non-block 200 that is_bot_block_page() correctly did
not flag (it had a title), but which carried zero
data-hook="review" markup.docs/specs/amazon-reviews-scraper/recon/degraded_page_probe.py, local,
Apify RESIDENTIAL, this Actor's exact production fetch config incl.
script blocked): reproduced the exact page — a real 542 KB response, a
real productTitle, a real acrCustomerReviewText rating-count widget
(aria-label="385 Reviews", so the product plainly has reviews) — but
zero data-hook attributes anywhere in the document. The "Top
reviews" widget the 0.5 pivot believed was server-rendered is
client-side injected and needs JS to populate; that pivot's "5/5 clean
with script blocked" validation (2026-08-26) was on too small a sample
and never had a committed recon script, so the actual failure mode
(Amazon serving the JS-dependent variant) went undetected until it
dominated the public success rate. Saved as
tests/fixtures/review_page_degraded.html.src/client.py::BLOCKED_RESOURCE_TYPES: script removed — only
image/media/font/stylesheet stay blocked (pure cost, no review
content lives there). RENDER_SETTLE_MS raised 2_000 -> 4_000 to give
the now-unblocked client-side hydration time to run before page.content()
is read. This reintroduces the ~10-14 MB/ASIN residential transfer the 0.5
pivot cut to save cost — flagged for a human to reconsider pricing on,
not addressed here (pricing is out of scope for a fixer pass; a
non-delivering Actor already earns nothing, so restoring delivery is
strictly better even before that's revisited).src/parser.py::is_bot_block_page: gained a third, defense-in-depth
signal — a title AND a positive review count from the (non-JS-dependent)
acrCustomerReviewText widget AND zero rendered review blocks is now
treated as a degraded/unusable render (soft block), not a genuinely
review-less product, so the caller rotates and retries instead of
silently accepting it and failing the ASIN/run. A genuinely review-less
product has no rating-count widget at all
(tests/fixtures/review_page_empty.html), so this can't misfire on a
real zero-review product — directly implements
DEVILSCRAPES-CONTEXT.md's "find a positive signal for really empty"
rule for the ambiguous-200 case.tests/test_client.py::test_script_not_blocked (pins script
stays out of BLOCKED_RESOURCE_TYPES so a future cost pass can't
silently reintroduce this), tests/test_parser.py:: test_is_bot_block_page_true_on_degraded_page_with_review_count_but_no_blockscheck + format --check; also
cleared 3 files of pre-existing line-length drift unrelated to this fix —
src/models.py, src/scraper.py, tests/test_scraper.py — needed for a
green ruff format --check gate), pyright clean.pbS8id34BhUjEyR7h (build 0.6.1, shipped
tests/fixtures/input.qa.json): SUCCEEDED, 5/5 real review rows
(rating/review_text/review_date/reviewer_name/verified_purchase/
helpful_vote_count all populated), chargedEventCounts matched delivery
exactly. Re-exercises the exact B0BSHF7WHW page that failed "0 reviews"
on live build 0.5.3 — see docs/specs/amazon-reviews-scraper/notes.md
2026-09-14 08:46 entry for the full record.recent_failures empty — this Actor's own runs weren't among
them). The 2026-08-25 triage (build 0.4.1) fixed a real fault-isolation
bug but left the Actor non-delivering: Amazon soft-blocked residential
exits 5/5 on two ASINs, and no NO-GO could be written because
_ensure_residential made the datacenter tier untestable from the
Actor's own input. This entry establishes the actual verdict named in
both tiers.scripts/recon/tier_probe.py, local, direct proxy-URL
construction bypassing _ensure_residential entirely — unambiguous
tier attribution since there's no fallback layer at that boundary):
RESIDENTIAL and BUYPROXIES94952 (datacenter), 2 ASINs x 4 attempts each,
pinned country-US. 0 of 16 attempts reached real review content on
either tier. Worse: of the 2/16 that got a genuine 200 (not a
bot-check interstitial — real title, real page), both had zero
data-hook="review" markup — a real page missing the widget, not a
block. Confirmed independent of proxying: an unproxied local fetch got
the identical stripped page.scripts/recon/camoufox_probe.py, local, Apify
RESIDENTIAL pinned country-US, pattern copied from
actors/idealista-property-scraper/src/recon_camoufox.py commit
89a78ce): the same URL, same proxy pool, fetched by a real browser
instead of curl-cffi, returns the reviews server-rendered in the
initial document response — no JS execution needed to populate them.
3/3 clean fetches on ASIN B0BSHF7WHW (13 reviews each), 1/1 on
B09B8V1LZ3 (8 reviews) — a genuinely dead ASIN (B08N5WRWNW, 404 even
unproxied/no-proxy) was ruled out as the cause of the earlier "second
ASIN" blocked-reading in the 2026-08-25 notes. Verdict: GO — this is
a client-fingerprint problem (Amazon serves a different document by
TLS/H2 fingerprint), not an anti-bot IP block and not a JS-rendering
requirement.script at the route-handler level (alongside the existing
image/media/font/stylesheet block) was validated live (5/5 clean
fetches, same review counts) and cuts per-ASIN transfer to src/client.py: AmazonReviewSession is now Camoufox-based —
AsyncCamoufox launch (static locale="en-US", no geoip=True per
the documented crash mode in
actors/vrbo-vacation-rentals-scraper/src/browser.py), a route
handler blocking image/media/font/stylesheet/script, and the
same retry/rotate state machine as before (408/429/5xx retry,
403/429/soft-block-200 rotate, 400/401/404/410 fail loud) except
rotation now relaunches the browser on a freshly-minted proxy session
instead of swapping a curl-cffi impersonation profile. resolve_proxy_url()
(REQ-8, WEBSHARE_PROXY_URL env-first) is unchanged.src/main.py::_build_session: awaits the new AmazonReviewSession.create()
async factory instead of a synchronous constructor (browser launch is
inherently async)..actor/Dockerfile: apify/actor-python-playwright:3.11 base image +
python -m camoufox fetch build step, structural copy of
actors/vrbo-vacation-rentals-scraper/.actor/Dockerfile.pyproject.toml: curl-cffi dropped, camoufox[geoip] + playwright added..actor/actor.json: memory raised (512/2048/512 -> 1024/4096/2048
min/max/default) — a headless browser needs materially more headroom than
a bare HTTP client; matches actors/vrbo-vacation-rentals-scraper's
Camoufox memory profile. Version bumped 0.4 -> 0.5.tests/test_client.py, tests/test_main.py, tests/test_smoke.py:
rewritten to mock/drive the Playwright Page surface instead of a
curl-cffi session; test_smoke.py's opt-in live check now exercises
Camoufox directly (single non-retrying navigation, matching the old
test's intent). test_scraper.py/test_parser.py/test_models.py
untouched (fake-session/pure-parser, no interface change). 80 hermetic
tests green (1 smoke test opt-in, unchanged), ruff clean, pyright
clean, verify_input_prefill.py / verify_no_scaffold_stub.py /
verify_entrypoint_runs.py all green.recent_failures
for this Actor were empty (all customer-side), so reproduced directly with two
fresh apify api cloud runs against the live build — t1Ju4E9EVIorWMJOZ and
cbASLiLAYFYrWR1qC — both FAILED with the identical log signature: attempt 0
hits an HTTP-200 soft block and correctly rotates, then attempts 1-4 all fail
with curl: (7) CONNECT tunnel failed, response 590 on the exit that rotation
just minted, exhausting all 5 attempts and failing the ASIN (0 rows -> whole
run FAILED). scripts/os/run_usage.py confirms both runs genuinely moved
bytes over PROXY_RESIDENTIAL_TRANSFER_GBYTES — this is not a proxy-tier
regression (RESIDENTIAL was actually used, not silently downgraded to
datacenter); it's a fault-isolation gap in the client's retry loop.src/client.py::AmazonReviewSession._attempt: the network-error branch
(RequestException/OSError, which is how curl-cffi surfaces a dead/blocked
proxy tunnel) logged, slept, and retried on the same session — unlike the
403/429 and soft-block-200 branches, it never called self._rotate(). A dead
tunnel is a property of the exit IP, not the request, so retrying without
rotating just re-dials the same broken exit until retries run out. Fixed to
rotate (fresh browser profile + fresh Apify proxy session_id) on network
error too, matching the existing rotate-on-block paths.tests/test_client.py: added test_network_error_triggers_rotation and
test_persistent_network_error_exhausts_retries_and_rotates_each_time
(mirrors the existing 403/429 rotation tests); also fixed
test_retry_then_success_after_network_error to mock _rotate, since it
now exercises a code path that constructs a real curl_cffi.AsyncSession —
under this test suite's known process-wide asyncio.sleep monkeypatch (see
the 0.3 CHANGELOG entry's "Bonus bug"), that briefly hung the test run.
82 tests green (1 smoke test skipped, opt-in), ruff clean, pyright clean.fix/amazon-reviews-scraper-network-error-no-rotate,
named this exact root cause but carried zero commits beyond origin/main —
checked via git merge-base --is-ancestor, confirmed empty, superseded here.{FAILED: 6, SUCCEEDED: 1}, 14%
success, failures still accumulating as of the 08-03/08-05 snapshots):
compared two cloud QA runs from build 0.2.1 that already ran the
0.1/0.2 fixes — wCnILYz9DB0d7e4MK (FAILED, statusMessage: "Scraped 0 reviews across 1 ASIN(s): B0BSHF7WHW (no-results)"TiDTHYXnIXMOPwZGI (SUCCEEDED, 5 real review rows) — same ASIN, same
build, three minutes apart. The failing run's log shows exactly one
soft block (HTTP 200) — rotating session line, then a real,
non-block 200 response that is_bot_block_page() correctly does
not flag (it has a productTitle) but that embeds zero
data-hook="review" blocks — a real Amazon page, just missing the
Top-reviews widget. The succeeding run needed 3 rotations before
landing on a working exit and returned 5 rows for the identical
ASIN. The only thing that varies run-to-run is which residential exit
gets minted; per today's cross-actor finding (bestbuy.com
country-selector splash, Viator JPY pricing), residential proxy
exits are geo-random, and amazon.com renders a different,
reviews-less layout for a non-US-recognized visitor without ever
tripping a bot-check marker. The actor never pinned an exit country,
so ~1 in a few rotations silently produced this false-empty result
instead of erroring.src/main.py::_resolve_proxy_configuration: now calls
Actor.create_proxy_configuration(groups=..., country_code="US")
instead of passing the raw proxyConfiguration input straight
through — every request is pinned to a US residential exit
(PROXY_COUNTRY_CODE), and RESIDENTIAL is force-included
(_ensure_residential) even if a caller's proxyConfiguration input
omits it. marketplace_domain is a single-value "amazon.com" enum
in v1, so hardcoding US is in-scope, not a workaround.tests/test_main.py: two new tests pin that
_resolve_proxy_configuration always passes country_code="US" and
always includes "RESIDENTIAL" in groups, regardless of what the
input's proxyConfiguration dict contains.test_proxy_session_id_matches_apify_regex,
Gate 9's regression test), ruff clean, pyright clean,
scripts/verify_input_prefill.py re-verified./publish-actor's Gate 1 and Gate 7): added
.actor/icon.png (rendered from the existing icon.svg via
qlmanage, matching scripts/upload_actor_icons.py's fallback
path) and tests/test_smoke.py (opt-in -m smoke, live fetch of
ASIN B0BSHF7WHW's product page, asserts parseable reviews) — this
actor had neither before, unlike the google-ads-transparency
reference implementation.tests/conftest.py's
autouse _patch_sleep fixture called
monkeypatch.setattr(client_mod.asyncio, "sleep", ...) —
client_mod.asyncio is the real, global asyncio module object (a
Python import doesn't copy it), so this silently replaced
asyncio.sleep process-wide for every test, not just calls made
from src.client. That starves curl-cffi's async transport (which
depends on genuine event-loop scheduling to service a live socket),
turning a real network fetch into an indefinite CPU-spinning hang
instead of a clean timeout — reproduced directly: the first draft of
test_smoke.py hung >3 minutes at ~60% CPU with this patch active,
and passed in under 2s once the fixture was scoped to skip
smoke-marked tests. Fixed via request.node.get_closest_marker ("smoke")test_client.py
still pass unaffected (they're not smoke-marked).recent_failures at build
0.1.1 (vvSBwVsHWFjaF44YX, PImgd1oHcBK0rI5pT, both started
2026-08-01 after the 0.1 soft-block fix was already live) via
apify runs info — both failed in 6-11s with statusMessage: "Invalid input: 1 validation error for ActorInput. Value error, Provide at least one of asins or product_urls."INPUT KVS record showed every
field at its input_schema.json default — asins: [],
productUrls: [] — not the prefill value (["B0BSHF7WHW"]).
prefill only backs the interactive Console form; a run started
without customizing every field (bare API call, integration,
platform health-check) gets the schema's default, and
asins.default had drifted to [] while asins.prefill stayed a
real ASIN — so any such invocation hard-failed REQ-3 immediately.
This is a distinct bug from the 0.1 soft-block fix (confirmed via
fresh log pulls, not assumed) and was invisible to
scripts/verify_input_prefill.py's existing Gate 3c because that
check only reconstructs the prefill payload, never default..actor/input_schema.json: asins.default now matches
asins.prefill (["B0BSHF7WHW"]) instead of [] — a bare/default
invocation now runs a real (small, demo) scrape instead of failing
loud on empty input. ActorInput's REQ-3 cross-field validator is
unchanged: a customer who explicitly clears both fields and submits
still gets a clear validation error, as intended.tests/test_models.py: new test_schema_default_input_is_runnable
reconstructs the exact payload Apify merges for an un-customized
run (every property's schema default, mirroring the real
vvSBwVsHWFjaF44YX/PImgd1oHcBK0rI5pT INPUT records) and pins that
it must pass ActorInput.model_validate — regression guard for this
default/prefill drift class, since Gate 3c alone doesn't catch it.verify_input_prefill.py
re-verified against the updated schema.apify-actor-start/apify-default-dataset-item events, not this
repo's custom pay_per_event.json events — main.py's
Actor.charge() calls remain no-ops on the live platform pending
reconciliation.apify api
cloud runs against build 0.0.1 — of 3 fresh runs on the same ASIN,
one FAILED with statusMessage: "Scraped 0 reviews across 1 ASIN(s): B0BSHF7WHW (no-results)"marketing/opportunities/SCRAPER-BACKLOG-2026-07-29.md item #1)
intermittently soft-blocks the Actor's proxy exit IPs: it answers
with HTTP 200, not a 403/429, so client.py's existing retry/rotate
logic — which only branches on status code — never engaged. The
blocked page has no productTitle and no data-hook="review"
blocks, so parse_review_page correctly found zero reviews and
main.py correctly failed a run with a genuinely empty result — the
bug is that a soft block was silently treated as "this product has
no reviews" instead of "retry with a fresh session", exactly as
client.py's original module docstring called out as scraper.py's
responsibility but which was never wired up.src/parser.py: adds is_bot_block_page() — detects Amazon's
bot-check interstitial via known text markers
(BOT_BLOCK_TEXT_MARKERS, industry-documented, not recon-captured
this session — flagged for re-verification against a live capture)
plus a structural fallback (no product title AND no review blocks;
a real product page always has a title, even with zero reviews).src/client.py: AmazonReviewSession.get_page() now accepts an
optional is_blocked predicate; a 200 response it flags rotates the
proxy session + browser profile and retries, identical to the
existing 403/429 path, instead of being returned as real content.src/scraper.py: wires parser.is_bot_block_page into
session.get_page(...).src/models.py, .actor/input_schema.json: proxyConfiguration
default/prefill now includes apifyProxyGroups: ["RESIDENTIAL"] —
Amazon is an anti-bot-prone target per
DEVILSCRAPES-CONTEXT.md's anti-blocking-stack rule; the actor
previously defaulted to Apify's datacenter proxy group.tests/test_client.py (soft-block rotate+retry,
exhausted-retries FetchError, backward-compat no-predicate path),
tests/test_parser.py (is_bot_block_page true/false cases incl.
a real zero-review product staying False), tests/test_scraper.py
(regression pin that is_bot_block_page is actually wired into
get_page).amazon.com/product-reviews/<ASIN> (the
originally-planned all-reviews listing page) 200s but silently
redirects to amazon.com/ap/signin — it is login-walled, not
anti-bot-walled (no CAPTCHA/JS-execution challenge; confirmed via
r.url after redirect and inspecting the sign-in HTML). No
curl-cffi impersonation profile change fixes an auth gate.amazon.com/dp/<ASIN> (the product page) is not login-walled —
200, no redirect, and it embeds a real, keyless "Top reviews from
the United States" widget (data-hook="review" blocks; 8 observed
on a live sample fetch, data-hook="total-review-count" showing
~196k total ratings the widget does not paginate through over plain
HTTP).amazon.com/dp/<ASIN> (typically 6-10 per ASIN), not a full
paginated review corpus. This is a narrower but real, live-confirmed
surface — see docs/specs/amazon-reviews-scraper/spec.md "Wire
format" for the full pivot rationale.src/parser.py: selectors are now live-confirmed (not placeholders)
against a real fetch; fixed TITLE_CSS (h5[data-hook="reviewTitle"],
not a[data-hook="review-title"]) and BODY_CSS
(div[data-hook="reviewRichContentContainer"], not
span[data-hook="review-body"]) to match real markup. All other
selectors matched the original hypothesis exactly.src/scraper.py: removed the /product-reviews/ pagination loop
(sortBy/pageNumber, MAX_PAGES_PER_ASIN); now a single fetch of
amazon.com/dp/<ASIN> per ASIN. Dedupe (REQ-10) kept as a defensive
guard against duplicate markup on one page.src/models.py: dropped sort_by/sortBy (only meaningful for the
removed pagination); max_reviews_per_product ceiling lowered from
2000 (default 100) to 20 (default 10) to reflect the real, smaller
surface — no longer misleading about corpus size..actor/input_schema.json, README.md: updated to describe "top
reviews from the product page" honestly instead of a full,
paginated corpus; dropped the sortBy input field.tests/fixtures/review_page_page1.html /
review_page_empty.html now mirror the real /dp/<ASIN> markup
structure confirmed via live recon (data-hooks, tag names, nesting)
with anonymized review text/names — not blind synthetic guesses.verify_input_prefill.py re-verified
against the updated input_schema.json..actor/ (actor.json, input/output/dataset schemas, PPE
events, Dockerfile, icon), src/__init__.py + src/__main__.py
entry point, tests/conftest.py + tests/fixtures/input.qa.json,
README skeleton.src/models.py, src/client.py, src/parser.py, src/scraper.py,
and src/main.py are not implemented yet — see
docs/specs/amazon-reviews-scraper/tasks.md (T02-T11).src/recon_cloud.py, orchestrator-owned,
never shipped) has not yet confirmed the wire-format hypothesis in
docs/specs/amazon-reviews-scraper/spec.md ("Wire format") — parser
selectors are placeholders pending that recon.