Finn Torget Scraper: Norway New Listing Alerts

Watch a search, get only what's new — and what sold. This actor runs your search against FINN Torget's own search-results pages — Norway's largest general classifieds marketplace — and returns one clean row per listing: title, price, condition, brand, and a permanent link. Turn on monitoring and it becomes a watchlist: new listings, price drops, and gone ones since your last run, charged per row, free on quiet days. Gone listings double as a FINN Torget sold items tracker, with a lifetime sell-through rate on every row. Schedule it hourly and send the results to Discord, Slack, Google Sheets, or n8n.

Who it's for

A reseller or arbitrage buyer watching one category (phones, bikes, electronics) for underpriced or newly-posted listings wants a live feed of what's actually on FINN Torget right now, without refreshing the search page by hand or installing a browser extension like Torgvakt — which exists only because FINN's own Torget has no saved-search alerts. A market-research team tracking asking prices for a product category, or a Sheets/n8n workflow that reacts the moment something new is posted, gets the same shape here: paste a list of search terms, get back a flat row per listing, and pay only for listings actually returned — a search that finds nothing costs nothing.

This actor covers FINN Torget (general for-sale) only. FINN's vehicle listings are a separate, already-published actor in this catalogue, finn-listing-lookup, and this actor doesn't touch or replace it. It is FINN's member of the same Nordic classifieds family as blocket-listing-lookup (Sweden) and tori-listing-lookup (Finland) — all three run on the same Schibsted/Vend "recommerce" platform, so the same search shape and monitoring model work the same way on each.

Why this one

• Monitoring first, not a one-off dump. Turn on "Only return results that are new, or dropped in price" and this actor becomes a watchlist: it remembers every listing ID it has already shown you, and only bills you for what's actually new or has dropped in price since the last run. A quiet run — nothing new, nothing cheaper — still finishes and costs only the base run fee.
• A sold signal, honestly labelled. Turn on "Alert on gone listings" and a listing this watchlist tracked but can no longer find comes back once as gone, with a sellThroughRate on every row. FINN never confirms a sale, so this is a "delisted" signal, not a receipt — see "Sold signal and sell-through" below for exactly how it's detected and its honest limits.
• Reads FINN's own structured listing data. Every base field comes from the same seoStructuredData JSON-LD block Blocket.se embeds for search engines on this shared platform — not text scraped from rendered HTML — so price, currency, condition, and brand are exact, typed values.
• Never charged for a miss, or a quiet monitoring run. A search that finds nothing, or a scheduled watchlist run where nothing changed, still gets a row explaining what happened — and costs nothing. See "Pricing" below for the found-row rate.
• Honest about what FINN doesn't expose statically. FINN's search and item pages don't serve a posted-time or seller identity anywhere in the static response (confirmed directly, not assumed) — this actor doesn't fabricate those fields. See "Data & privacy" and the FAQ for what that means and what you do get from the optional details hop.
• Paste a keyword or your own saved search URL. Type plain keywords, or paste a FINN search-results URL you've already filtered on the site — its filters carry straight through.

What you get

One row per listing by default (turn off "Expand rows" in Advanced to get one row per search instead, with the listings nested under listings).

Deselect any field in the Input tab's column picker to drop it from every row — query, found, status, message, and scrapedAt always stay.

Pricing

• Listing returned: $2 per 1,000 listings
• Listing details fetched: $1 per 1,000 listings

Plus a $0.002 start fee per run. Each event above is billed independently, only when it actually returns data — misses (found:false) are never charged.

listing-details only fires when "Fetch extra details per listing" is on, and only for listings actually delivered that run — a listing dropped by monitoring never triggers a details fetch, so you never pay for a detail hop on a row you didn't get. Gone rows are ordinary listing rows — there is no separate "sold signal" event and no extra request is made for one.

Monitoring / only new results

Turn on "Only return results that are new, or dropped in price" and a search line becomes a watchlist instead of a one-off dump:

• A listing counts as new the first time its FINN listing ID is returned by this watchlist.
• A listing counts as a price drop when its price falls by at least "Minimum price drop" (5% by default) since it was last seen — measured against the most recently seen price, so a listing that drops twice is compared against its latest price each time, not its original one.
• Already-seen, unchanged listings are dropped before you're billed. A quiet run — nothing new, nothing cheaper — still finishes and returns one free row with monitorStatus: NO_NEW_ROWS, so a scheduled task shows it actually ran.
• The first run has nothing to compare against. By default it returns everything it finds as "new" (so you see your whole current search result once). Turn on "Seed silently" to instead have the first run bank everything quietly with zero rows and zero charge, and start alerting from the second run on — this is what stops a fresh watchlist from firing a hundred "new listing" messages into your Discord channel on day one.
• Sort is forced to FINN's own newest-first order whenever monitoring is on, so two runs of the same watchlist are always comparing the same ordering.

Schedule recipe. Save this actor as an Apify Task with deltaMode: true and a deltaName you choose, add an hourly (or daily) Schedule, and point the task's webhook at Discord, Slack, Google Sheets, or an n8n/Make webhook URL to get pinged only when something actually changes.

Price-drop window limitation. A price drop is only ever seen while the listing is still inside what a run actually fetches — if a listing falls out of your maxListingsPerSearch window or your price filters between runs, this actor has no way to notice it dropped. Keep searches reasonably narrow (a specific model, a tight category) rather than one huge catch-all if price-drop coverage matters to you.

Sold signal and sell-through

Turn on "Alert on gone listings (sold signal)" and a listing this watchlist has tracked, but that a later run can no longer find, comes back once as changeType: "gone" — a FINN Torget sold items tracker. Be honest about what that means: FINN never confirms a sale. gone most often means sold, but sometimes it means the seller withdrew it, deleted it, or edited it out of your search filters. gonePresumedSold narrows that a little further: it's true only when the listing was seen on 2 or more consecutive runs and its last known price was at or under that run's median price — a rough "this one was priced to move" heuristic, not proof.

How detection works. Every run checks, before deciding anything is gone, whether it can trust the result:

• Complete fetch. If this run's paging reached FINN's own "Du finner N annonse(r)" total with no failed page, every matching listing came back — any previously tracked listing missing from it is gone, regardless of order.
• Feed position. Monitoring forces FINN's newest-first sort. This actor checks, on every run, that the search-result cards' own relative-age labels ("11 min.", "1 t.", "2 t.") really are non-decreasing down the page before it trusts position at all — because a seller renewing a listing moves it back toward the top without it being a new post (confirmed live: one listing on the probe page used FINN's old 2021-era image URL format yet sat 4th from the top with a 10-minute age). A listing that was near the top last run and is missing now, with nothing newer or renewed to explain the gap, is gone. A listing near the bottom edge of the window, or within 2 places of a crossed 53-listing page boundary, is left alone that run rather than risk a false "gone".
• No gone check at all on a first run, an empty fetch, a blocked or failed page, an unverified and incomplete fetch, or a hand-named watchlist run under different price filters than it was built with.

Billing. Gone rows are ordinary listing rows — no separate event, no extra request (a gone row is rebuilt entirely from what an earlier run already saw). They're only returned when "Alert on gone listings" is on, but they're always counted toward goneCount and sellThroughRate, so the rate is accurate from day one even if you only turn the checkbox on later. Each gone listing is reported once; if it reappears (a reservation that fell through, a relisting), it's quietly taken back off the lifetime count and isn't re-alerted.

Example.

{"searches": ["stone island jacket"], "maxListingsPerSearch": 192, "deltaMode": true, "deltaName": "sold-signal-stone-island", "alertOnNew": false, "alertOnPriceDrop": false, "alertOnGone": true}

How to use

1. In the Apify Console. Open the actor page and click Start — the searches 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~finn-torget-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"searches":["iphone"]}'
   

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.

4. Turn on "Only return results that are new, or dropped in price" under Monitoring once you want a watchlist instead of a one-off dump — see "Monitoring / only new results" above.

Input

{
  "searches": [
    "iphone"
  ]
}

One per line — plain keywords (e.g. "iphone", "sofa") or a full search-results URL copied from finn.no/recommerce/forsale, including any filters it already has. No login required. Covers FINN Torget (general for-sale) only — for vehicle listings use this catalogue's finn-listing-lookup instead. Accepted formats: iphone, sofa, https://www.finn.no/recommerce/forsale/search?q=sykkel&price_to=2000.

Sample output

A search that finds nothing comes back as a row with "found": false and is never charged. A quiet monitoring run comes back as a row with "found": true, "monitorStatus": "NO_NEW_ROWS" and is also never charged.

How to filter

Every filter below is optional and off by default — leave it out and you get exactly the same rows as before. minPrice/maxPrice/includeKeywords/excludeKeywords already existed (the latter two match anywhere in the row — title, description, brand, condition, etc. — not just the title). This section adds conditions, availability, cities and brands. A filtered-out listing is dropped before it's billed — you never pay for a row you didn't get.

1. Only "Used"-condition iPhones under 5,000 NOK:

{
  "searches": ["iphone"],
  "maxPrice": 5000,
  "conditions": ["good"]
}

conditions matches FINN's own itemCondition (New → new, Refurbished → like_new, Used → good, Damaged → fair; no grade at all → unknown) — never guessed from the title. FINN has no "new with tags" concept, so new_with_tags never matches anything here.

2. A named brand only:

{
  "searches": ["telefon"],
  "brands": ["apple"]
}

brands is a case-insensitive "contains" match against the listing's own brand field — no extra request, and this actor keeps paging (up to its normal page budget) until it has enough matching rows, not just enough rows looked at.

3. Exclude a keyword from the title, with per-listing city (needs details on):

{
  "searches": ["sykkel"],
  "excludeKeywords": ["defekt", "deler"],
  "cities": ["oslo"],
  "includeDetails": true
}

cities matches the listing's city as a case-insensitive "contains" — but city is only known once includeDetails fetches the item page, so cities narrows nothing when that's off (documented in the input's own help text). availability exists too, but FINN's search feed never shows a sold listing (a sold one is simply delisted — see "Sold signal" above), so it's a no-op kept only for input-shape consistency with the rest of the portfolio.

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~finn-torget-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"searches":["iphone"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~finn-torget-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"searches":["iphone"]} (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~finn-torget-listing-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"searches":["{{search}}"]}, mapping the row's search into the searches array.

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

For monitoring, point the Task's webhook (Console → your Task → Webhooks) at a Discord or Slack incoming-webhook URL, a Google Sheets automation (via Zapier/Make/n8n listening for the webhook), or an n8n/Make workflow's own webhook trigger, so new listings and price drops land wherever you actually work instead of a dataset you have to remember to check.

Tips

• Start monitoring with "Seed silently" on for any watchlist you're setting up on a schedule — it avoids a wall of "new" alerts for your entire current search result on day one.
• Keep a monitored search reasonably narrow (a model, a tight category, a price band) — see "Price- drop window limitation" above for why a huge catch-all search misses price drops on listings that fall outside what gets fetched.
• Turn on "Fetch extra details per listing" only when you actually need city or category — it adds one request (and one listing-details charge) per delivered listing.
• A BLOCKED status means FINN returned a 403, 429, or 503 — lowering "Max concurrency" or trying again shortly usually clears it; this actor doesn't need a proxy by default.
• Paste your own already-filtered FINN search URL instead of rebuilding filters in this actor's Input tab — anything the URL already filters on carries straight through.
• For a sold-signal watchlist, set maxListingsPerSearch comfortably above how many new listings typically appear between runs — the position check needs headroom to tell "slid out of view" from "actually gone".

vs. Torgvakt, and vs. blackfalcondata/finn-torget-scraper

The "Torgvakt" Chrome extension exists purely to bolt saved-search alerts onto FINN Torget, because FINN's own Torget has none built in — it only works in one browser, on one device, while that browser tab stays open. This actor gives you the same "only tell me what's new" behavior as a plain HTTP call or a scheduled Apify Task with a webhook into whatever tool you actually use, from anywhere.

The current Apify Store leader for FINN Torget, blackfalcondata, has 13 users on Torget and zero reviews — a one-off dump, no monitoring mode. This actor works across any Torget category, adds new-listing, price-drop and sold-signal monitoring as first-class modes, and bills only for listings actually delivered.

Data & privacy

This actor reads public search results that anyone can see without logging in. It doesn't log in, solve CAPTCHAs, or reveal hidden contact details. Seller identity is off by default: FINN doesn't expose a seller id, name, or type anywhere in the pages this actor reads, so none is output. Contact-info-like strings (emails, phone numbers) inside a listing's description are redacted to [redacted]. Turning on seller info in a future version of this actor would make you responsible for having a lawful reason to process it. Not affiliated with FINN / Schibsted.

Is this allowed? It collects the same public listing data your browser shows, for the searches you choose. It's built for monitoring a search, not for copying the marketplace. Check that your use fits FINN's terms and your local law.

FAQ

Why is a row empty, or why does found say false? Either the input line was blank (status: BAD_FORMAT), FINN returned a 403/429/503 (status: BLOCKED), or the search matched nothing on FINN right now (status: NOT_FOUND). Check the message column for the specific reason. None of these are billed.

Am I charged for a quiet monitoring run? No. When monitoring finds nothing new and no price drops, you get one row with monitorStatus: NO_NEW_ROWS and listingCount: 0 — Actor.charge() only fires when listingCount is greater than zero.

Does this return posted-time or seller name? No. FINN's search and item pages don't serve either statically (confirmed directly against the live site) — this actor doesn't fabricate them. You get listing details (title, price, condition, brand, image, description) plus, with "Fetch extra details per listing" on, city and full category path from the item page.

What does "Fetch extra details per listing" actually fetch? One extra request per delivered listing to that listing's own FINN item page, for its city, full category path, and full (redacted) description. It's billed as a separate listing-details event and is automatically skipped, at no charge, whenever the proxy configuration is set to RESIDENTIAL.

Can I paste my own filtered FINN search instead of using this actor's price filters? Yes. Paste the full search-results URL from your browser's address bar as a search line — any filters already in it (price range, category) carry through unchanged.

Do I need to configure proxies? No. This actor uses Apify's default proxy configuration (no proxy group) out of the box — FINN doesn't block plain requests from Apify's datacenter IPs. RESIDENTIAL is available as a fallback if that ever changes.

Does it find sold listings? What is the sell-through rate? Turn on monitoring plus "Alert on gone listings" and a listing this watchlist can no longer find comes back once as changeType: "gone". FINN never confirms a sale, so treat it as a delisted signal, not a receipt — see "Sold signal and sell-through" above for exactly how it's detected, its gonePresumedSold heuristic, and its limits. sellThroughRate (lifetime gone ÷ tracked) is tracked for every watchlist regardless of whether "Alert on gone listings" is on.

Can an AI agent call this directly? Yes. It's registered on the Apify MCP server — an agent in Claude, Cursor, or another MCP client can find and run it by name ("Finn Torget Scraper | Apify"), or you can call the REST endpoint shown above from any script or workflow tool.

Related actors

• Blocket Scraper — the same search and monitoring shape for Blocket.se, Sweden's largest classifieds marketplace (same Schibsted/Vend platform family).
• Tori Scraper — the same shape for Tori.fi, Finland's largest classifieds marketplace.
• Finn.no Vehicle Listing Lookup — FINN's vehicle listings, a separate, already-published actor in this catalogue that this one doesn't touch.