Homes.co.nz Scraper

Collect rich residential listing data from homes.co.nz using structured site data.

What it does

• Supports search mode from plain location names such as Wellington.
• Supports url mode for detail URLs and map URLs.
• Accepts multiple locations or multiple URLs in one run.
• Advances forward across structured result pages without relying on DOM pagination.
• Pulls structured listing data directly from the site's underlying data sources.
• Enriches each listing with property card data, agent and branch details, title metadata, valuations, media, and open home schedules.
• Applies structured filters for listing status, bedrooms, bathrooms, and price range.
• Supports output sorting by publication time or numeric price when available.

Why this actor is different

The actor is structured-data first:

• Detail pages are resolved from the page's server-rendered state and then enriched with listing data.
• Map pages are resolved from the page's server-rendered state and then expanded into individual listings.
• Property enrichment adds valuation, title, branch, and agent data.

That keeps extraction faster and more stable than page-structure parsing.

Input

• mode: search or url
• locations: one or more location names for search mode
• urls: one or more Homes detail or map URLs for URL mode
• listingStatus: for_sale, for_rent, just_sold, or off_market
• minBedrooms, minBathrooms, minPrice, maxPrice: structured query filters
• sortBy: default ordering, newest, oldest, highest price, or lowest price
• maxListings: maximum number of listings to output (default 20; the sole soft cap on a run — 0 = unlimited)
• maxPages: output pages to emit per search target. Leave empty (0) to walk every result page — bounded only by maxListings and the site's own candidate ceiling. Set a number only for an explicit page cap.
• pageSize: listings to emit per output page
• resumeFromRunId: optional. Paste a previous run ID or dataset ID to continue a large walk-all pull — listings already saved by that run are loaded before scraping starts and skipped, so this run only appends new listings. Independent of incrementalMode below.
• fetchPropertyCards: whether to include extra property enrichment
• includeRawApiResponses: include raw structured payloads in output for debugging

Resume & recurring updates

• resumeFromRunId (see Input above) continues one interrupted crawl.
• incrementalMode (default false) is for recurring/scheduled monitoring of the same search or URLs: the actor remembers the previous run itself (a key-value baseline keyed on the tracked search, not a run ID you paste) and tags each listing with:
  • changeType: NEW, UPDATED, UNCHANGED, REAPPEARED, or EXPIRED
  • changedFields: which top-level fields differ from the previous run (empty for NEW/UNCHANGED/REAPPEARED/EXPIRED)
  • firstSeenAt / lastSeenAt: UTC timestamps for this state key
• stateKey (optional): override the auto-derived tracked-search identity. Auto-derivation hashes mode + locations/urls + listingStatus/minBedrooms/minBathrooms/minPrice/maxPrice + fetchPropertyCards (toggling this changes the comparable field set, so it must start a new baseline). It deliberately excludes maxListings, maxPages, pageSize, sortBy (output caps/ordering, not scope), proxy/debug/notification fields, and the resume/incremental controls themselves.
• emitUnchanged (default false): when off, a listing identical to the last run is not pushed again — a recurring run only bills for what changed. Turning it on returns (and bills) a row for every unchanged listing too.
• emitExpired (default false): when on, and only after a run completes a full pass of the tracked search (a capped/partial/resumed run never does this), a listing that dropped out since the last run is pushed once more with changeType: EXPIRED. This bills an extra row per dropped listing.
• The identity key across runs is the same listing id the in-run dedup set already uses (listingId, falling back to id — same underlying value).
• Combining incrementalMode with resumeFromRunId is only supported for the first incremental run for a given state key (bootstraps the resumed ids as known-present placeholders); once a real incremental baseline exists, combining the two fails fast rather than guessing.
• A field transition where either side is missing/null is never treated as a change — only a genuine value → different value transition counts. This also protects against a failed detail fetch: it never enters the tracked baseline (no false UPDATED/billing on a transient error), and a leaner-but-successful fetch that happens to omit a field carries the prior value forward instead of looking like a change.

Send results into your apps (MCP connectors)

Optionally pipe the scraped results into the apps you already use, via Model Context Protocol (MCP) connectors. This is an extra delivery step after the scrape — the Apify dataset is never changed.

What gets written to the connector: a condensed, human-readable summary of each record — not the full JSON. Each item becomes one entry with a title (the listing's name / address) and its key fields flattened to plain text (price, beds/baths, agent, URL, …). Nested objects are collapsed to their main value (e.g. an address object → its full-address text) and long lists are trimmed to the first few names. The complete, full-fidelity record always stays in the Apify dataset — the connector copy is a readable digest for browsing in your app.

• Notion → one page per item (title + a summary body), created under the page you set in notionParentPageUrl.
• Linear / Airtable / other → one record/issue per item with the same title + fields.

How to enable:

1. Authorize a connector once under Apify → Settings → Integrations (Notion, Linear, Airtable, or Apify).
2. Select it in the "Pipe results into your apps" input field. (If the picker is empty, you haven't authorized a connector yet.)
3. For Notion, also set notionParentPageUrl to the page where items should be created.

The connection is mediated by Apify's MCP proxy, so this actor never sees your third-party credentials. Leave the field empty to skip — the export only runs when a connector is selected.

Output highlights

Each item contains the standard listing fields plus richer structured sections such as:

• openHomes
• images
• media
• agents
• branch
• propertyDetails
• valuations
• estimates
• titleRecord
• sourceEndpoints
• seedContext

In incrementalMode, each item also carries changeType, changedFields, firstSeenAt, and lastSeenAt — see Resume & recurring updates above.

Notes

• This actor is tuned for structured site data first.
• If a Homes URL changes shape, the fallback is still the page's embedded state rather than page selectors.