How to Scrape EdgeProp.sg Singapore Property Data in 2026

Singapore’s residential market moves on price-per-square-foot, and EdgeProp.sg is one of the few portals that surfaces PSF, tenure and market segment on every listing. The problem: there is no public EdgeProp API, and if you point a plain curl at a category page you get the first ~20 listings and nothing else — the rest is rendered client-side and hidden behind pagination the site never fully exposes. This guide covers how EdgeProp actually serves its data, why naive scraping caps out at a page of results, and how to pull thousands of clean, deduplicated Singapore property records — plus the agent behind each one — in a single run.

What’s worth extracting

EdgeProp normalizes a lot of what you’d otherwise have to derive by hand. Per listing you get roughly 35 fields, which group into five useful clusters:

• Pricing — price (numeric SGD), priceRaw (the string as shown, e.g. S$ 2,110,900), priceCurrency, and psf (price per square foot). PSF is the field that makes cross-project comparison possible.
• Size and layout — floorAreaSqft and floorAreaSqm, plus landAreaSqft / landAreaSqm for landed homes (both null on condos and HDB flats), bedrooms and bathrooms.
• Location — project / development name, street, postalCode, district (the postal district, e.g. 11), planningRegion (e.g. Central Region) and projectRegion, the market segment: CCR / RCR / OCR (Core Central, Rest of Central, Outside Central Region).
• Tenure and age — tenure (Freehold vs 99-year leasehold, etc.), yearCompleted, and the isNewLaunch / developerListing flags.
• Agent leads — agentName, agentId (the agent’s CEA registration number), agency, agentPhone and agentUrl. This is what turns a market-data pull into a broker outreach list.

There’s also listingId (the stable dedup key), the canonical url, image and imageCount, updatedAt and a scrapedAt timestamp. For most price-intelligence work you need the pricing, size, location and tenure fields; for lead-gen you want the agent cluster.

How EdgeProp actually serves its data

EdgeProp.sg is a Next.js app. Like most Next.js sites, it embeds the data for the current page as structured JSON inside the initial HTML payload (the hydration data the front-end uses to render). This actor reads that embedded listing data directly — no headless browser, no login, no API key. That’s why datacenter proxy is enough and runs stay cheap: you’re parsing JSON that ships with the page, not driving Chrome.

The category URLs are predictable and human-readable, which is what you paste into startUrls if you want to target a specific segment:

https://www.edgeprop.sg/condo-apartment-for-sale
https://www.edgeprop.sg/hdb-for-rent
https://www.edgeprop.sg/landed-for-sale

Any /all suffix and trailing query string are normalized automatically, so you can copy a URL straight from your browser. If you’d rather not deal with URLs, the propertyType (condo / hdb / landed / any) and listingType (sale / rent / room) selectors build the right category for you.

A minimal run — condos for sale, capped at 1,000 rows — looks like this:

{
  "propertyType": "condo",
  "listingType": "sale",
  "maxResults": 1000
}

▶ Open the EdgeProp.sg Scraper on Apify — one run returns price, PSF, district, tenure and the listing agent (name, CEA ID, agency, phone) for thousands of Singapore listings. No login, no key. Export to CSV, Excel or JSON.

The access reality: why a bare URL gives you 20 rows

Here’s the friction that trips up first-time scrapers. A bare EdgeProp category URL renders only the first page — about 20 listings. The site paginates the rest client-side, and there’s no clean public endpoint to walk every page. So a naive “fetch the category, parse the listings” approach returns 20 rows and stops.

The actor’s answer is price-band sharding (priceShardSharding, on by default — this is what the README calls high-volume mode). Instead of hitting one category and taking the top 20, it slices each category into a series of asking-price bands and pulls each band separately, then deduplicates by listingId. Because each band returns its own page of results, sharding a category into enough bands surfaces thousands of unique listings instead of a single page. Turn it off only if you genuinely want just the top ~20 per category.

Two more knobs matter for throughput and cost:

• maxConcurrency (1–6, default 4) — how many price-band requests run in parallel per category. Higher is faster but heavier.
• Proxy — datacenter (the default) works fine on EdgeProp; the site doesn’t run an aggressive anti-bot stack against the embedded-data path. Switch proxyConfiguration to RESIDENTIAL only if you hit persistent challenges, since residential bandwidth costs more.

Set maxResults to 0 for no cap, or a number to keep a run inside budget. maxResultsPerSearch caps each category independently if you’re sweeping several at once.

Example output

One flat row per listing. A representative condo record (agent details included):

{
  "listingId": "m_1980317",
  "url": "https://www.edgeprop.sg/listing/apartment-condo/condominium/26-NEWTON/m_1980317",
  "listingType": "sale",
  "propertyType": "Apartment / Condo",
  "project": "26 NEWTON",
  "street": "Newton Road",
  "postalCode": "307957",
  "district": "11",
  "projectRegion": "CCR",
  "price": "2110900",
  "priceRaw": "S$ 2,110,900",
  "psf": "1886",
  "bedrooms": "2",
  "floorAreaSqft": "1119",
  "tenure": "Freehold",
  "yearCompleted": "2016",
  "agentName": "Martin Goh",
  "agentId": "R001839F",
  "agency": "REALSTAR PREMIER GROUP PRIVATE LIMITED",
  "agentPhone": "93202020",
  "scrapedAt": "2026-06-07T10:31:24.950Z"
}

Note agentId is a CEA registration number, and agentPhone is parsed from each agent’s public CEA profile URL — present on most listings, empty where EdgeProp doesn’t expose it.

Typical use cases

What people actually build on this data:

• Market analysis across districts and segments — track asking prices, PSF and inventory, and slice by district or CCR / RCR / OCR to see where the money sits.
• Rental yield and PSF research — pull both sale and rent for a project or district and compute gross yield per project.
• Agent and brokerage lead generation — build targeted outreach lists (name, CEA ID, agency, phone) filtered by area, price band or property type.
• Investment screening — filter condo / HDB / landed by tenure, year completed, size and price to shortlist deals.
• Price tracking and alerts — re-run on a schedule and diff against the prior dataset to catch new listings and price movements.
• Feeding portals, dashboards or valuation models — power a Singapore property feed, a BI dashboard or an ML valuation model from a scheduled run.

Build-it-yourself vs. managed actor

You could build this yourself. The Next.js embedded-data trick isn’t hard to reverse-engineer, and datacenter proxy keeps the bill low. But the real work isn’t the first fetch — it’s the price-band sharding logic that gets you past 20 rows, the dedup by listingId, the agent-phone lookup against CEA profile URLs, and keeping all of it green when EdgeProp reshapes its hydration payload (which Next.js sites do on redeploys).

On the managed side, EdgeProp is one of the cheap ones: no browser, datacenter proxy, and pay-per-result pricing means you’re paying a fraction of a cent per listing row plus a tiny per-run start fee. For a weekly sweep of a few thousand listings across segments, that’s low single digits per month — versus a proxy subscription plus the maintenance hours you’d spend chasing a moved JSON key.

Common pitfalls

Specific gotchas worth knowing before you commit to an EdgeProp pipeline:

• Sharding is not optional for volume. If you leave priceShardSharding off, you get ~20 rows per category and will wrongly conclude the actor “misses listings.” Keep it on for anything beyond a spot check.
• landArea* is null for non-landed. Condos and HDB flats have no land area — don’t treat null there as missing data; it’s correct.
• agentPhone is best-effort. Most listings expose it via the CEA profile URL, but a minority don’t. Build your outreach flow to tolerate an empty phone rather than dropping the row.
• PDPA applies to agent data. agentName, agentId and agentPhone are personal contact details. You’re responsible for handling them under Singapore’s PDPA and EdgeProp’s terms — this is publicly visible data, but that’s not a blanket license to spam.
• Segment coverage needs per-segment runs. For a full picture across condo/HDB/landed and sale/rent, run each segment (or paste multiple category URLs) with high-volume mode on — one bare category won’t cover the island.
• Store listingId as your join key. Titles and prices change between runs; listingId is the stable identity for diffing new-vs-existing listings over time.

Wrapping up

If you need a one-off snapshot of a single district, the selectors and a modest maxResults get you there in minutes. If you need a refreshed Singapore property feed — with PSF, tenure, segment and the agent behind each listing — the sharding, dedup and agent-lookup logic is worth not rebuilding yourself.

▶ Run the EdgeProp.sg Scraper on Apify — condo, HDB and landed, sale and rent, with price, PSF, district, tenure and agent leads (CEA ID + phone) on every row. No login, no API key, datacenter-cheap. Export to CSV, Excel or JSON, and start on Apify’s free monthly credit.