Dorotheum.com Auction & Artist Scraper
Pricing
from $7.50 / 1,000 results
Dorotheum.com auction scraper — real unpaywalled realized prices back to 1998, upcoming estimates, and artist profiles, with built-in delta mode.
Pricing
from $7.50 / 1,000 results
Rating
0.0
(0)
Developer
Artsiom Kunitsyn
Maintained by CommunityActor stats
0
Bookmarked
3
Total users
2
Monthly active users
12 days ago
Last modified
Categories
Share
"currentAuctions": upcoming, not-yet-resolved lots (estimates/starting bids only). "auctionResults": historical, resolved lots with real realized prices — the full archive back to 1998 by default. "artists": the artist directory. Each produces a different output shape (see dataset_schema.json).
Optional list of specific Dorotheum auction URLs (e.g. https://www.dorotheum.com/en/a/123940/) or artist URLs (e.g. https://www.dorotheum.com/en/k/alvar-aalto/) — use whichever kind matches entityType. Scope is always "custom", with no delisting-detection or persisted incremental baseline (a hand-picked list is necessarily partial) — leave empty for the full sitemap-driven crawl instead.
Stop after pushing this many dataset items (lots or artists). Defaults to 50 — a fast, cheap preview, and what keeps an unconfigured run within Apify's automated 5-minute QA check. A full auctionResults crawl covers the entire historical archive (thousands of auctions, each with many lots) — raise this or clear it (set to null) for that; note a capped run never updates the incremental baseline (see mode below).
"auto" (recommended): for auctionResults/artists, full scan on the first run for a scope, incremental (new/changed only) afterwards. For currentAuctions specifically, "auto" always behaves as a full refresh every run regardless of an existing baseline — upcoming auctions are a small, frequently-changing dataset where a full refresh is more useful than a delta. "full": always push every item and refresh the baseline. "incremental": always push only new/changed items. Only a plain, unscoped crawl (no startUrls) can detect delistings or update the baseline.
curl_cffi browser TLS-impersonation target. Dorotheum's Cloudflare Bot Management challenges plain (non-impersonated) requests, so this defaults to "firefox" internally — confirmed live that "chrome" specifically gets blocked from Apify's own infra while "firefox" clears cleanly (same requests, same infra, only the TLS fingerprint differs). Override only if "firefox" stops working.
Apify Proxy configuration. Leave off — confirmed on real Apify infra that default egress clears Cloudflare fine with the default "firefox" impersonation target (see the impersonate field above). An earlier build wrongly blamed IP reputation for a 403 that was actually caused by the "chrome" impersonation target's TLS fingerprint; proxies were tested at the time and didn't help either, consistent with it never having been an IP issue.
{ "useApifyProxy": false}