Imovirtual & Storia Property Scraper — Portugal, Romania

Scrapes property listings from Imovirtual (Portugal) and Storia (Romania), the leading OLX Group real-estate portals in each market — the same platform family as otodom-properties-scraper (Poland), already in this portfolio.

Market	Site	Example scale (apartments for sale)
Portugal	imovirtual.com	~16,400 in Lisbon district, ~74,400 nationwide
Romania	storia.ro	~22,700 in Bucharest, ~82,000 nationwide

Residential and commercial, buy and rent, with optional full listing details.

---

What each row contains

Every listing is emitted as upstream returns it. Highlights:

• Price (totalPrice), area, rooms, floor
• Location — full address text and coordinates
• Advertiser — agency name and logo, or private owner
• Listing metadata — creation date, image count, development/investment linkage for new-build units
• With includePropertyDetails: the full description, a structured characteristics table (price/m², build year, energy certificate), features by category, owner contact details including phone numbers, breadcrumbs, and floor plans

Record types

recordType	One per	Purpose
SEARCH_SUMMARY	query	upstream's own total, requests spent, honesty flags
PROPERTY	listing	the listing itself, upstream shape preserved
ERROR	failed input	so every input maps to at least one row

---

The one filter to be careful with

Property type is the dangerous input on this platform. An unrecognised value is not rejected — it returns HTTP 200 with every listing in the whole country, and it discards your location filter too. searchApplied on the summary row reports whether this happened; when it did, the Actor stops before crawling and emits zero property rows rather than filling your dataset with the wrong data. This Actor validates the type against each market's real list before ever sending the request, so this should not come up in normal use — it exists as a safety net and as documentation for anyone calling the underlying URL pattern directly.

Everything else offered here was individually verified to move the result count: transaction, rooms, price range, area range and sort each narrow or reorder genuinely, on both markets independently — Romania's default sort already puts newest first, for instance, so "Newest first" is a no-op there even though it works on Portugal.

---

Input

Field	Notes
market	pt (Imovirtual) or ro (Storia)
locations	Location slugs, e.g. lisboa, porto, bucuresti, cluj. Empty = whole country
transaction	comprar/arrendar (PT), vanzare/inchiriere (RO)
propertyType	See the market's allowlist in the input description
rooms	Multi-select, 1 through 10+
minPrice / maxPrice	EUR
minArea / maxArea	m²
sortBy / sortDirection	Price, area, or newest
pageSize	24, 36, 48 or 72 — anything else silently falls back to 36
includePropertyDetails	One extra request per listing
maxItems	Per location

---

Known limits

• No artificial pagination ceiling — a whole-country apartment query pages through several hundred pages. Narrow by location, type or price for a quicker, more targeted crawl.
• Pagination clamps past the last page rather than erroring — page 458 of a 457-page result re-serves page 457. The Actor detects this (no new ids) and reports paginationClampHit: true rather than looping.
• totalMatches is read from page 1 only. The live index shifts under a running crawl.
• otodom.pl (Poland) is not included here — it already ships as its own Actor in this portfolio (otodom-properties-scraper), even though it runs the same platform.
• Listings removed mid-run answer 404 on the detail pass. The search row is still emitted, with detailFetched: false.

Anti-bot

None encountered. Seven TLS fingerprints were tested against search pages (page 1 and page 5) on both markets — all 28 combinations returned data cleanly, cold, with no warmup. The Actor still rotates fingerprints and exit IPs on failure, and defaults to residential proxy, because cloud egress is fingerprinted differently from a local test.