willhaben Listing Lookup

Look up any listing on willhaben.at, Austria's largest online marketplace for vehicles, real estate, and general classifieds — price, title, status, and the full category attribute set (mileage, make, model, fuel type, transmission for vehicles; the equivalent raw attributes for every other category). This is not an official willhaben API: the actor fetches the public listing page and reads the same structured data the page itself renders from. Re-check the same URLs on a schedule and turn on Monitoring to get a willhaben sold items tracker: a sold listing checker with a sell-through rate, not just a one-off lookup — see Sold signal and sell-through.

Features

• URL → structured listing record. Ad ID, title, status, price (numeric and as-displayed), and currency.
• Vehicle-specific fields. Make, model, mileage (km), fuel type, transmission, and model year, pulled straight out of the listing's own attribute set.
• Every category attribute, raw. A attributes map with every name/value pair willhaben stores on the listing, so non-vehicle categories (real estate, general marketplace) aren't left with empty fields.
• Sold signal and sell-through. Turn on Monitoring and re-check the same URLs on a schedule to get a willhaben sold items tracker: a listing that disappears becomes a gone row with a sell-through rate, not just a silent miss — see Sold signal and sell-through.
• Pay only for hits. Removed, expired, or invalid listing URLs cost nothing — see Pricing.
• Built for bulk. Feed in thousands of listing URLs; concurrency and proxy group are both configurable.

How to use willhaben Listing Lookup — Price & Vehicle Attribute API

1. In the Apify Console. Open the actor page and click Start — the items field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~willhaben-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"items":["https://www.willhaben.at/iad/gebrauchtwagen/d/auto/ford-kuga-2-5-duratec-fhev-st-line-x-aut-821587098"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

Input

{
  "items": [
    "https://www.willhaben.at/iad/gebrauchtwagen/d/auto/alfa-romeo-mito-...-991753367",
    "/iad/gebrauchtwagen/d/auto/some-other-listing-123456789"
  ],
  "maxConcurrency": 5,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

items is a list of willhaben listing identifiers — full listing URLs (the /iad/.../d/... permalink) or bare paths, which are resolved against https://www.willhaben.at automatically. maxConcurrency (default 5, max 20) controls how many listings are fetched in parallel; keep it conservative, since this target has no browser fallback if it starts blocking. proxyConfiguration defaults to the Residential proxy group — plain datacenter IPs get a 403 from this target, so leave the default in place unless you know your setup works around it.

Monitoring (optional, off by default) — add these to items above to turn repeated runs on the same URLs into a sold items tracker:

{
  "items": ["https://www.willhaben.at/iad/gebrauchtwagen/d/auto/alfa-romeo-mito-...-991753367"],
  "deltaMode": true,
  "deltaName": "my-watchlist",
  "alertOnGone": true
}

See Sold signal and sell-through for what this does and how it's billed.

Output

One row per input item, for example:

{
  "query": "https://www.willhaben.at/iad/gebrauchtwagen/d/auto/alfa-romeo-mito-...-991753367",
  "found": true,
  "data": {
    "adId": "991753367",
    "title": "Alfa Romeo MiTo 1.4 TB MultiAir Distinctive",
    "status": "ACTIVE",
    "price": 8990,
    "priceDisplay": "€ 8.990,-",
    "currency": "EUR",
    "make": "Alfa Romeo",
    "model": "MiTo",
    "mileageKm": 87000,
    "fuelType": "Benzin",
    "transmission": "Manuell",
    "yearModel": "2010",
    "attributes": { "...": "every raw attribute name/value pair from the listing" },
    "image": "https://cache.willhaben.at/...",
    "url": "https://www.willhaben.at/iad/gebrauchtwagen/d/auto/alfa-romeo-mito-...-991753367"
  },
  "scrapedAt": "2026-08-20T12:00:00.000Z"
}

A listing that's been removed, expired, or was never valid — willhaben 308-redirects those to an unrelated category page with no listing data — comes back as { "query": "...", "found": false, "scrapedAt": "..." } and is never charged.

With Monitoring off (the default), that's the whole shape — data carries a block of monitoring fields (changeType, firstSeenAt, sellThroughRate, ...) that are always null, so a run's output shape never changes just because the feature exists. See Sold signal and sell-through for what they hold with Monitoring on.

Use cases

• Track price changes on specific vehicle, real estate, or marketplace listings over time.
• Pull mileage, fuel type, and transmission across a shortlist of cars for side-by-side comparison.
• Check whether a batch of previously-seen listings is still active or has been removed/sold.
• Build a structured dataset from category attributes for local market research.
• Verify a listing URL is live and resolvable before linking to it elsewhere.
• Run a willhaben sold items tracker on a shortlist of comparable listings (a make/model, a neighbourhood) and read off the sell-through rate over weeks.

Sold signal and sell-through

Turn on deltaMode and schedule this actor daily on the same items to get a willhaben sold items tracker. Each run re-fetches the exact URLs you gave it — this is a URL lookup, not a search feed — so "not found this run, but found last run" is a direct, observable signal: no feed position or arrivals model is needed (unlike this portfolio's search actors, which have to guess whether a listing merely slid off a results page or genuinely disappeared).

Honesty note. gone means delisted, not sold: willhaben never confirms a sale. A gone listing is most often sold, but can also be withdrawn, expired, or edited into a different id. gonePresumedSold: true is a heuristic — the listing was seen on 2 or more consecutive runs (so it wasn't a one-off blip) and its last known price was at or under this run's median price — not a fact.

How detection works here. Every URL in items gets its own memory record (in a named store, scoped by deltaName) holding its last known price and how many runs in a row it's been seen. The first time a URL comes back not-found after having been seen before, that's the gone event — reported once, then quiet even if you keep re-checking the same dead URL (a "tombstone"). If the ad reappears later (a reservation falling through, a relist), it's taken back off the lifetime gone count and reported as an ordinary sighting, not a second "new".

Billing. A gone row is an ordinary, billed item-lookup row — found: true, same as any other result about a URL you asked about — not a new pricing event. It's counted toward sellThroughRate and goneCount from the moment deltaMode is on, even if alertOnGone is off; alertOnGone only controls whether that specific row is returned to you (and therefore billed) this run. That's why turning Monitoring on never changes an existing scheduled run's cost by itself — only turning alertOnGone on does, and only on the runs that actually find a gone listing.

What every found row also carries with Monitoring on: changeType (new / seen / price_drop), firstSeenAt, lastSeenAt, daysListed, and the watchlist-wide goneCount / trackedCount / sellThroughRate / medianPrice. Unlike a search actor's "only return new listings" feed, no row is ever withheld here — every URL you list is explicitly yours to re-check, so alertOnNew and alertOnPriceDrop don't drop anything; they exist so your own filter (Sheets, n8n) can key off changeType the same way as this portfolio's other monitoring actors. Only alertOnGone gates a row, because a gone row has no real page to fetch in the first place — it's rebuilt from the last sighting's snapshot.

Example: track a shortlist for sold signals.

{
  "items": [
    "https://www.willhaben.at/iad/gebrauchtwagen/d/auto/alfa-romeo-mito-...-991753367",
    "https://www.willhaben.at/iad/gebrauchtwagen/d/auto/another-listing-123456789"
  ],
  "deltaMode": true,
  "deltaName": "shortlist-2026",
  "alertOnGone": true
}

Schedule it daily. The first run only seeds the watchlist (every URL is new) — there's nothing to compare against yet, so it can't show a gone row. From the second run on, any URL that's disappeared comes back as a billed gone row.

Limits. medianPrice is the median of each URL's last known price across this run's batch (not a live re-fetch of every URL at once), so it can lag a same-run price change elsewhere in the batch — acceptable for a signal field that is never used for billing. The per-URL memory forgets a URL 30 days after its last sighting (then a 5,000-URL cap per watchlist as a backstop); a URL forgotten this way and later found again is treated as brand new, not a comeback.

Pricing

$2 per 1,000 results, plus a $0.00005 start fee. Misses (found:false) are never charged.

With Monitoring on, a gone sold-signal row bills exactly the same way as any other result row — no separate event, no extra fee — and only when alertOnGone returns it. See Sold signal and sell-through.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~willhaben-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"items":["https://www.willhaben.at/iad/gebrauchtwagen/d/auto/ford-kuga-2-5-duratec-fhev-st-line-x-aut-821587098"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~willhaben-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"items":["https://www.willhaben.at/iad/gebrauchtwagen/d/auto/ford-kuga-2-5-duratec-fhev-st-line-x-aut-821587098"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~willhaben-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"items":["{{value}}"]}, mapping the row's value into the items array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "willhaben Scraper | Apify" — the agent will find and run this actor.

FAQ

What can I put in items? Full willhaben listing URLs (the /iad/.../d/... permalink), or a bare path starting with /iad/... — those get the https://www.willhaben.at domain prepended automatically.

What happens if a listing was removed or the URL is wrong? willhaben 308-redirects invalid or expired listing IDs to an unrelated category page that has no advertDetails in its data. The actor treats that as not-found, records found: false, and does not charge for it.

Is this using an official willhaben API? No — willhaben doesn't publish one. The actor requests the public listing page and reads the same __NEXT_DATA__ JSON the page uses to render itself, which is more stable than parsing rendered HTML but is still a page scrape, not a documented API contract.

Why do vehicle listings have more fields than other categories? The make/model/mileageKm/fuelType/transmission/yearModel fields are convenience shortcuts pulled from vehicle-specific attribute keys. Every category — vehicles included — also gets the full raw attributes object, so real estate or general marketplace listings aren't missing data, just the named shortcuts.

Do I need to change the proxy configuration? No, and you generally shouldn't. This target returns HTTP 403 through the shared datacenter proxy pool but works through Residential, which is the default — only touch it if you have a specific reason to.

How high can I set maxConcurrency? Up to 20, but the default of 5 is a reasonable starting point. This target has no browser fallback, so a burst of concurrent requests that trips anti-bot defenses costs you more (blocked, unpaid requests) than a slower, steady crawl.

Does it find sold listings? Yes — turn on deltaMode and re-run the same items on a schedule. willhaben never confirms a sale, so this is a sold items tracker with a heuristic (gonePresumedSold), not a certainty. See Sold signal and sell-through.

Will Monitoring change what I get today if I don't turn it on? No. deltaMode defaults to off, and off means byte-for-byte the same behaviour as before this feature existed — found rows just gain a block of monitoring fields that are always null.