SeLoger Listings Scraper

Scrape SeLoger.com (France's #1 real estate portal) from a search-results URL you paste — no need to configure filters in this actor, just set them on seloger.com and copy the resulting URL.

Features

• Scrape any SeLoger search (sale or rent, any city/price/room filter you set on their site)
• Returns per-listing: price, transaction type, property type, rooms/bedrooms, surface m², location, agency/contact, photos, and listing URL
• Uses SeLoger's own embedded search-results JSON (window["initialData"]) — no HTML scraping, no browser
• Pay per result — you only pay for listing records actually extracted
• Automatic pagination up to maxItems, with residential-proxy session rotation on a block

Input

Field	Type	Default	Description
searchUrl	string	(required)	A seloger.com search-results URL. Set your filters on seloger.com, then copy the URL from your browser.
maxItems	integer	100	Max listings to return (0 = unlimited)
proxyConfiguration	proxy	RESIDENTIAL FR	Apify Residential proxy, France — required for reliable access

Why a search URL instead of filter fields?

SeLoger's location filter uses opaque internal place/geo IDs, not plain postal codes or city names — several of the Store's own traction-proven SeLoger scrapers (azzouzana/seloger-mass-products-scraper-by-search-url, memo23/seloger-scraper) use the same "paste your search URL" contract for exactly this reason. Guessing the ID scheme wrong would silently return 0 or wrong-city results, which is worse than asking the buyer to copy a URL.

Output fields

Field	Description
listing_id	SeLoger internal listing ID
url	Direct URL to the listing (may be null — see caveats)
title / description	Listing headline / summary
transaction_type	sale or rent
property_type	apartment, house, etc.
price / price_per_m2 / monthly_price	EUR
rooms / bedrooms / surface_m2 / floor
energy_class / ges_class	DPE/GES letter grade (search-card level; full detail needs the listing page)
city / district / postal_code / department
latitude / longitude
agency_id / agency_name / agency_phone / agency_link	agency_name is the contact display name shown on the search card, which may be an individual agent rather than the agency brand
photos / photo_count / virtual_visit_url
is_new / is_exclusive / tags
publication_date
page_number / source / parse_confidence / warnings / scraped_at	Provenance/QA fields

Access path

SeLoger has no public search API. Its search-results page is server-rendered and ships the full result set as a double-encoded JSON literal inside an inline <script> tag: window["initialData"] = JSON.parse("...") — the argument is itself a JSON-encoded string, so it decodes twice (JS-string-unescape, then json.loads). This actor fetches that page with curl_cffi (Chrome TLS impersonation, no browser) and decodes it directly — no HTML/CSS-selector parsing on the happy path.

Third-party scraping vendors document SeLoger as running anti-bot fingerprinting/CAPTCHA challenges (DataDome-class) against non-residential traffic, so Apify RESIDENTIAL (FR) proxy is required for production reliability, per this fleet's access-ladder convention (see _shared/transport.py).

Honest caveats (read before relying on this in production)

• Field-name mapping is unverified against a live SeLoger response. The initialData field names used here (price, surface, cardType, cityLabel, zipCode, contactName, phoneNumber, classifiedURL, …) come from ScrapFly's public engineering write-up on scraping SeLoger, not from an authenticated cloud run against the live site (out of scope for this build — no live/paid access path was exercised). normalize.py is defensive by design: every field falls back to None and deducts parse_confidence rather than raising, so a wrong/renamed key degrades gracefully instead of crashing the run — but the exact field set should be spot-checked against a real cloud run (with a real RESIDENTIAL FR proxy) before this actor is published or relied on for paid delivery.
• The exact top-level "cards" container key is unconfirmed. The parser locates the listing array by a tolerant structural walk (first list of dicts that "look like" listing cards — has an id plus signal fields), not a hardcoded dotted path, specifically because the wrapper key wasn't confirmed live. This is the same tolerant-fallback pattern already used by immoscout24-listings in this fleet.
• url is never fabricated. If no URL-shaped field is found on a card, url is null with a url_missing warning rather than guessing a possibly-wrong deep-link scheme.
• Full DPE/GES, exact address, and co-ownership charges live on the detail page, not the search-card payload — this actor is search-summary-only (matching the sibling immoweb-properties-scraper's pre-fetchDetails scope). Detail-page enrichment (also JSON-embedded, via __NEXT_DATA__ on the property page per the same ScrapFly source) is a straightforward v2 addition once the search-card path is verified live.
• Termination is by empty-page detection (not a parsed totalItems count), since the exact total-count key name is also unconfirmed — this trades a slightly less precise pagination estimate for correctness under an unverified schema.

Tests

Unit tests (tests/) run entirely offline against synthetic fixtures — no live network calls: cd actors/REAL_ESTATE/seloger-listings-scraper && python3 -m pytest -q.