Tori Scraper: Finland New Listing Alerts

Watch a search, get only what's new. This actor runs your search against Tori.fi's own search-results pages — Finland's largest 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 and price drops since your last run, charged per new row, free on quiet days. Turn on "Alert on gone listings" and it is also a Tori sold items tracker: listings that disappeared from your search come back as gone (with a presumed-sold flag), plus a lifetime sell-through rate and the median price of the search. 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 Tori right now, without refreshing the search page by hand or checking back manually — Tori has no first-party saved-search alerting of its own. 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 is Tori's member of the same Nordic classifieds family as blocket-listing-lookup (Sweden) and finn-torget-listing-lookup (Norway) in this catalogue — Blocket, Tori, and FINN Torget all 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, not just new listings. With "Alert on gone listings" on, a watchlist also reports the listings that left the search since the last run, flags the ones that were probably sold (gonePresumedSold), and keeps a lifetime sellThroughRate for the search. See "Sold signal and sell-through" below for exactly how it decides, and what it can't know.
• Reads Tori's own structured listing data. Every base field comes from the same seoStructuredData JSON-LD block this platform family embeds for search engines — 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 Tori doesn't expose statically. Tori's search and item pages don't serve a seller identity anywhere in the static response (confirmed directly, not assumed), and the only time the search page carries is the feed's sort time, which a re-published listing resets — so this actor doesn't output a "posted" date it can't stand behind, and it doesn't pad out the item page's own ~160-character description limit either. See "Data & privacy" and the FAQ.
• Paste a keyword or your own saved search URL. Type plain keywords, or paste a Tori search-results URL you've already filtered on the site — its filters carry straight through.
• Nothing on this target has traction yet. Every current Apify Store rival for Tori is months old with zero reviews — this is a young market, not an entrenched one.

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).

Field	Type	Description
query	text	The search you submitted, echoed back
found	boolean	true if Tori returned a real search-results page for this search
status	text	OK on a match; NOT_FOUND, BLOCKED, or BAD_FORMAT on a miss
message	text	Plain-English reason for a miss — only present when found is false
searchQuery	text	The keyword actually searched (parsed out of a pasted URL, if you gave one)
listingCount	number	Listings returned and billed for this search
totalAvailable	number	Total listings Tori reports matching this search, including ones not returned
truncated	boolean	true if more results existed than were returned
newCount	number	New listings this run (monitoring only)
priceDropCount	number	Price drops this run (monitoring only)
goneCount	number	Listings that went gone this run, whether or not "Alert on gone listings" returns them (monitoring only)
sellThroughRate	number	Lifetime gone / tracked for this watchlist, 0 to 1 (monitoring only)
medianPrice	number	Median EUR price of every listing this run fetched for the search (up to maxListingsPerSearch), not only the rows returned (monitoring only)
detailsCount	number	Listings this run fetched the item-page details for
monitorStatus	text	NO_NEW_ROWS on a quiet monitoring run, WATCHLIST_SEEDED on a silent first run, otherwise empty
listingId	text	Tori's own numeric listing ID
title	text	Listing title
price	number	Price in EUR, or empty if the listing has no price
currency	text	Always EUR
condition	text	New, Used, Refurbished, or Damaged, as Tori labels it
brand	text	Brand, when Tori's listing has one
imageUrl	text (link)	First listing image
description	text	The listing's blurb; upgraded (though Tori itself truncates the item page's own text to roughly 160 characters) when details are fetched
city	text	Details only. The seller's city
category	text	Details only. Full Tori category path
changeType	text	new, price-drop, seen, or gone (monitoring only)
isNew	boolean	true on this listing's first appearance (monitoring only)
previousPrice	number	The price last recorded for this listing, when it dropped (monitoring only)
priceDropPct	number	Percentage drop from the previous recorded price (monitoring only)
firstSeenAt	date	When this watchlist first saw this listing (monitoring only)
lastSeenAt	date	The run that last saw this listing (on a gone row: its last sighting)
daysListed	number	Days between first and last sighting
lastPrice	number	Gone rows only. The last price seen before the listing disappeared
gonePresumedSold	boolean	Gone rows only. true when it was seen on 2+ consecutive runs and priced at or under this run's median
url	text (link)	Permanent listing link
scrapedAt	date	When this row was fetched

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.005 start fee per run. Each event above is billed independently, only when it actually returns data — misses (found:false) are never charged.

Gone listings ("Alert on gone listings") are ordinary listing rows: they count in listingCount and are billed like any other returned listing. There is no separate event, and with the checkbox off they are counted for sellThroughRate but never returned or billed.

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.

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 Tori 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 Tori's own newest-first order whenever monitoring is on, so two runs of the same watchlist are always comparing the same ordering.
• With "Alert on gone listings" on, a listing the watchlist saw last run that has left the search comes back once as changeType: gone. See the next section.
• A listing repeated across two result pages (it slid across a page boundary while the run was paging) is returned and billed once.

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

Tori never confirms a sale. A gone row means the listing was delisted: most often sold, sometimes withdrawn, deleted, expired, or edited so it no longer matches your search or price filters. gonePresumedSold: true narrows that to the likely sales: the listing was seen on 2 or more consecutive runs and its last price was at or under the median price of the listings this run fetched for the search (up to your maxListingsPerSearch). Everything else that disappeared is gone with gonePresumedSold: false.

How it decides. With monitoring on, Tori's search is sorted newest first by each listing's own publish (or re-publish) time. Listing ids are not in that order: a re-published listing keeps its old id, so "anything above the oldest id fetched" would count listings that merely slid out of view as sold. So each listing remembers its position in the feed. A listing seen last run that is missing now is gone only if, after counting every newer listing that arrived above it (new listings, re-published ones, and repeats across page boundaries), it should still have been inside what this run fetched, with a safety margin of 2 places or 5% at the bottom. When Tori's own match count proves the run fetched every matching listing, any missing listing is gone, whatever its position. Errors land on "still for sale", never on "sold".

When it doesn't judge. No gone check on a watchlist's first run, on an empty fetch, when a page was blocked or failed, when a page came back without Tori's feed data, when the feed wasn't in newest-first order (checked on every run), when Tori mixed in non-keyword results, or on the first run after you changed a named watchlist's filters. A listing close to where two result pages join is left for the next run.

Limits. Listings that disappear near the bottom of your window, or after they already slid out of it, are never reported: on a busy search, raise maxListingsPerSearch well above the number of new listings between two runs, or narrow the search. sellThroughRate is gone / tracked over the watchlist's lifetime within its memory (listings unseen for 30 days are forgotten, and it keeps at most 5,000). A listing reported gone that comes back is taken off the count and not re-alerted.

Billing. Gone rows are ordinary listing rows: counted in listingCount and billed like any other returned listing. No separate event, and a gone row never makes an extra request (it is rebuilt from what the watchlist saw last time, and "Fetch extra details" skips it).

Example: a daily sell-through watch

{
  "searches": ["iphone 13 128gb"],
  "maxListingsPerSearch": 200,
  "deltaMode": true,
  "deltaName": "iphone13-sell-through",
  "alertOnNew": false,
  "alertOnPriceDrop": false,
  "alertOnGone": true
}

Schedule it daily. The first run seeds the watchlist (no gone check); gone rows start on run 2. Use the Sold signals view in the dataset for gone rows, sellThroughRate and medianPrice.

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~tori-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", "sohva") or a full search-results URL copied from tori.fi/recommerce/forsale, including any filters it already has. No login required. Accepted formats: iphone, sohva, https://www.tori.fi/recommerce/forsale/search?q=polkupyora&price_to=200.

Sample output

query	found	status	searchQuery	listingCount	totalAvailable	truncated	newCount	priceDropCount	goneCount	sellThroughRate	medianPrice	detailsCount	monitorStatus	listings	listingId	title	price	currency	condition	conditionRaw	conditionBucket	listingStatus	brand	imageUrl	description	city	category	changeType	isNew	previousPrice	priceDropPct	firstSeenAt	lastSeenAt	daysListed	lastPrice	gonePresumedSold	url	scrapedAt
iphone	true	OK	iphone	100	6946	true	0	0				0		<all listings found (full list)>	48157799	Apple näytönsuojalasi 12 kpl iPhone 11 Pro / XS	15	EUR	Used	https://schema.org/UsedCondition	good	available	Apple	https://img.tori.net/dynamic/default/item/48157799/638315ca-04b8-4d24-b8d8-5c2f0f4bae0c	Apple näytönsuojalasi 12 kpl iPhone 11 Pro / XS												https://www.tori.fi/recommerce/forsale/item/48157799	2026-10-07T06:20:31.824Z

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 500 EUR:

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

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

2. A named brand only:

{
  "searches": ["gps"],
  "brands": ["garmin"]
}

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": ["polkupyörä"],
  "excludeKeywords": ["rikki", "varaosiksi"],
  "cities": ["helsinki"],
  "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 Tori'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~tori-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~tori-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~tori-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 "Tori 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 — the description upgrade it also fetches is capped at around 160 characters by Tori's own item page, not by this actor.
• A BLOCKED status means Tori 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 Tori search URL instead of rebuilding filters in this actor's Input tab — anything the URL already filters on carries straight through.

vs. checking Tori by hand, and vs. unfenced-group/tori-scraper

Tori has no first-party saved-search alert of its own — the only way to catch a new listing today is to keep reopening the search page. This actor gives you "only tell me what's new" as a plain HTTP call or a scheduled Apify Task with a webhook into whatever tool you actually use.

The current Apify Store leader for Tori, unfenced-group, has 11 users — and, like every other rival on this target, is months old with zero reviews, so nobody has established themselves here yet. This actor works across any Tori category, adds new-listing and price-drop monitoring as a first-class mode, plus a sold signal (gone listings, presumed sold, sell-through rate), and bills only for listings actually delivered.

	What it costs	What you get	Trade-off
This actor	Pay per listing returned; nothing for a miss or a quiet monitoring run	Any Tori category, monitoring mode (new + price drop + gone / presumed sold, sell-through rate, median price), optional city/category details	Posted-time and seller identity aren't available (Tori doesn't expose them statically); the details description is capped at ~160 characters by Tori itself
Checking Tori by hand	Free, but your own time	Whatever's on the page when you look	No alerting, no price-drop tracking, no record of what sold, and nothing while you're not looking
Doing it yourself	Your time to build and maintain a scraper, a seen-listing store, and a price-tracking layer	The same data	This actor's JSON-LD parsing, monitoring state, and redaction are the maintenance burden it absorbs

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: Tori 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 Tori / 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 Tori'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), Tori returned a 403/429/503 (status: BLOCKED), or the search matched nothing on Tori 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. Tori's pages don't serve a seller name statically (confirmed directly against the live site), and the only time on the search page is the feed's sort time, which a re-published listing resets, so it isn't output as a "posted" date. This actor uses it internally for the sold signal only. 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.

Does it find sold listings? What is the sell-through rate? Yes, as far as a public search allows. Turn on monitoring and "Alert on gone listings": listings that left your search since the last run come back as changeType: gone, and gonePresumedSold marks the likely sales (seen on 2+ runs, priced at or under the median). Tori never confirms a sale, so "gone" can also be a withdrawn or edited listing. sellThroughRate is the share of all listings the watchlist ever tracked that went gone. See "Sold signal and sell-through".

Why is the description sometimes cut off mid-sentence with details on? Tori's own item page truncates its description text to roughly 160 characters — this actor passes through what Tori actually serves rather than padding it out. Blocket and FINN Torget, the same family's other members, don't have this limitation.

What does "Fetch extra details per listing" actually fetch? One extra request per delivered listing to that listing's own Tori item page, for its city, full category path, and (subject to Tori's own truncation above) fuller 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 Tori 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 — Tori doesn't block plain requests from Apify's datacenter IPs. RESIDENTIAL is available as a fallback if that ever changes.

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 ("Tori 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).
• Finn Torget Scraper — the same shape for FINN Torget, Norway's largest general classifieds marketplace.