bruun-rasmussen-scraper

Scrapes auction lots and a cross-run artist rollup from Bruun Rasmussen — Denmark's oldest and largest auction house. Real realized prices, upcoming-lot estimates, and the cleanest price representation of any comparable actor — every price on the site is carried in a custom HTML element's numeric attribute, never a formatted string to parse.

Contents

• Key features
• Output
• Input
• Input examples
• Incremental (delta) mode
• How to scrape Bruun Rasmussen
• You might also like
• FAQ

🔑 Key features

• No text-parsing of prices, anywhere. Every estimate/realized-price figure on the site is carried in a custom <currency-amount amount="950.0" currency="DKK">/ <currency-range from="..." to="..."> HTML element — this Actor reads the raw attribute directly, never a locale-formatted string.
• Three entity types, one Actor. entityType: currentAuctions (not-yet-resolved lots), auctionResults (resolved lots with real realized prices — the default), or artists (a cross-run rollup — see below).
• No anti-bot friction at normal usage. No TLS-impersonation workaround needed. A large uncapped crawl can hit a real site-side rate limit — Apify Residential proxy (the default) meaningfully mitigates it; see Output's known gaps.
• Delta mode, tuned per entity type. auctionResults defaults to the usual auto-incremental behavior (full scan first run, changes only after). currentAuctions always fully refreshes every run instead.
• A real artist rollup, accumulated from auctionResults lots as they're crawled.

📋 Output

One dataset item per lot or artist, depending on entityType — see .actor/dataset_schema.json for the full field list, or the Output tab's per-entity-type views for a readable table.

Example lot record (resolved, sold):

{
  "source": "bruunrasmussen",
  "entity_type": "auctionResults",
  "external_id": "bruunrasmussen_BDE49E1A9E7F",
  "url": "https://bruun-rasmussen.dk/m/lots/BDE49E1A9E7F",
  "title": "Joakim Skovgaard",
  "artist_name": "Joakim Skovgaard",
  "artist_id": "365",
  "auction_number": "2633",
  "auction_title": "Paintings, furniture and varia, 10 August 2026",
  "category_name": "Paintings",
  "estimate_low": 4000.0,
  "estimate_high": 5000.0,
  "currency": "DKK",
  "sold": true,
  "price": 4600.0,
  "change_type": "new"
}

Example artist rollup record:

{
  "source": "bruunrasmussen",
  "entity_type": "artists",
  "external_id": "bruunrasmussen_artist_365",
  "name": "Joakim Skovgaard",
  "tracked_lot_count": 1,
  "tracked_total_price": 4600.0,
  "tracked_avg_price": 4600.0,
  "latest_lot_title": "Joakim Skovgaard",
  "latest_auction_number": "2633"
}

Results can be downloaded as JSON, CSV, or Excel from the Console's Output tab, or pulled via the Apify API/dataset endpoint.

Known gaps:

• A large uncapped run can hit a real site-side rate limit — mitigated by default, not eliminated. Confirmed live: sustained crawling on a static/datacenter IP triggers a block lasting over an hour. Apify's Residential proxy (the default here) was confirmed live across ~1,300 real requests to avoid that permanent block — instead producing occasional (~once per 90-300 items) short, self-healing stalls (a 30s timeout, ~5 min retry, then resumes), with zero errors and zero data loss in every real test so far. Real cost impact: roughly $0.73-0.85 per 1,000 items at this account's rates, still well under this actor's own per-item Store price. Not yet run at true full-archive scale — keep an eye on real usage over time.
• auctionResults is a rolling ~2-week recent-results window, not a deep historical archive. Confirmed live across multiple categories: resolved lots only stay queryable for roughly the current and immediately-past auction cycle. Great for tracking prices as auctions conclude (especially with mode: auto on a schedule), not for looking up decades-old results.
• The site's own status filter (used for discovery) is a coarse, occasionally-stale signal in both directions — confirmed live that it can include a lot that turns out not actually sold, or (rarer) a lot that's already resolved when discovered as "not yet resolved". This never affects what's in the output: sold/price always come from the lot's own page, never from the filter that discovered it.
• provenance/exhibitions are best-effort — parsed from free-text paragraphs prefixed "Provenance:"/"Exhibited:", not a guaranteed structured field. Anything that doesn't match lands in remarks instead of being dropped.
• entityType: artists does not crawl anything itself — it reads a rollup that auctionResults runs build up over time. Running artists before auctionResults has ever run pushes nothing (with a clear log message saying so). Given auctionResults is itself a rolling recent window, the rollup's numbers reflect recent activity accumulated over time — never a full sales history for an artist.
• Not every lot carries an artist attribution (e.g. books, coins, furniture without a named maker) — artist_name/artist_id are null in that case.

⚙️ Input

See .actor/input_schema.json for the full JSON schema.

Parameter	Type	Default	Description
entityType	String	auctionResults	currentAuctions, auctionResults, or artists.
startUrls	Array of strings	(none)	Specific Bruun Rasmussen lot URLs or bare 12-character lot ids to scrape directly. Ignored for entityType=artists. Scope is always "custom" — no delisting-detection, no persisted baseline. Leave empty for the full crawl instead.
maxItems	Integer	50	Stop after pushing this many dataset items (lots or artists). Defaults to a fast, cheap preview (also what keeps an unconfigured run within Apify's automated 5-minute QA check).
mode	String	auto	auto (recommended): the usual full-then-incremental behavior for auctionResults; always full for currentAuctions. full/incremental override this per run. Has no effect for entityType=artists.
impersonate	String	chrome (internal)	curl_cffi TLS-impersonation target. No bot-management signal was observed anywhere on bruun-rasmussen.dk while building this Actor, so this is set internally by default.
proxyConfiguration	Object	{"useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"]}	Apify Proxy config. Residential by default — confirmed live to meaningfully mitigate a real site-side rate limit that a static/datacenter IP hits on a large sustained crawl (see Known gaps).

🧪 Input examples

Quick preview of recent results (the default):

{ "entityType": "auctionResults" }

Every currently resolved lot across the full category tree (uncapped):

{ "entityType": "auctionResults", "maxItems": null }

What's currently up for bidding:

{ "entityType": "currentAuctions", "maxItems": null }

Artist rollup (run auctionResults at least once first):

{ "entityType": "artists", "maxItems": null }

A specific lot:

{ "entityType": "auctionResults", "startUrls": ["https://bruun-rasmussen.dk/m/lots/BDE49E1A9E7F"] }

Scheduled tracking run — full, uncapped run (maxItems cleared — required for the baseline to save and delistings to be detected):

{ "entityType": "auctionResults", "mode": "incremental", "maxItems": null }

🔄 Incremental (delta) mode

Every currentAuctions/auctionResults run classifies each lot as new, changed (sold/price moved), unchanged, or delisted, using a state baseline persisted in a named Apify Key-Value Store scoped to entityType. entityType: artists doesn't use delta mode at all — every run is a full snapshot of the current rollup.

• auctionResults: mode: auto (default) — first run for a scope pushes everything (full); later runs push only new/changed/delisted (incremental). Given the ~2-week rolling window, a scheduled mode: auto run is a genuinely good way to track newly-resolved lots as they land.
• currentAuctions: mode: auto always behaves as full, every run.
• A startUrls-scoped run is always partial and never updates the baseline or reports delistings.

Full design: ../../docs/incremental-mode.md.

🚀 How to scrape Bruun Rasmussen

1. Open the Bruun Rasmussen Auction Results & Artist Scraper in Apify Console and go to the Input tab.
2. Pick entityType (currentAuctions, auctionResults, or artists).
3. maxItems defaults to 50 (a quick preview) — clear it (set to null) for a full, uncapped run.
4. Click Start.
5. When the run finishes, browse results in the Output tab, or download as JSON/CSV/Excel, or fetch them via the API.
6. To track over time instead of scraping once: create a Schedule with mode: auto.

🔗 You might also like

• Dorotheum Auction Results & Artist Scraper
• Artcurial Auction Results & Artist Scraper
• Lempertz Auction Results & Artist Scraper

❓ FAQ

Is it legal to scrape Bruun Rasmussen? It's legal to collect publicly available auction-result data such as lot descriptions, prices, and sale information. Scrape it only with a legitimate purpose under GDPR.

How far back does auctionResults reach? Roughly the current and immediately-past auction cycle (~2 weeks), confirmed live — not a deep historical archive. Use a schedule with mode: auto to build up a longer record over time instead.

Why is price null for a resolved lot? It wasn't sold — check sold/state for the exact outcome.

Why does entityType: artists push nothing? It reads a rollup built up by entityType: auctionResults runs — it doesn't crawl anything on its own. Run auctionResults (ideally a full, unbounded run) at least once first.

Search keywords

bruun rasmussen scraper, auction house scraper, auction results scraper, art price data, art market analytics, realized price data, hammer price data, auction price index, art collector data feed