Realestate.co.nz Scraper at a glance
Realestate.co.nz Scraper is a ready-to-run Apify actor from abotapi for collecting real estate data. Its documented output includes change, changed fields, first seen, last seen and id, which you can export as JSON, CSV or Excel or read through the Apify API. It costs $1.80 per 1,000 results on the Apify Free plan and from $1.00 on paid plans, with smaller per-run or optional feature charges listed on Apify.
- Runs on
- Apify cloud: console, API, schedules and integrations
- Data type
- Real Estate, AI, Integrations
- Region
- Oceania
- Pricing
- $1.80 per 1,000 results (Free plan), from $1.00 on paid plans
- Output
- Documented below · JSON, CSV, Excel
- Inputs
- 24 options
Scrape Realestate.co.nz property listings across New Zealand. Search properties for sale, rent and sold, and extract available property details, prices, locations and listing information. Ideal for real estate research, property market analysis and price monitoring.
What Realestate.co.nz Scraper can do
- Two ways to search. Pick region, district and suburb filters, or paste realestate.co.nz search result page URLs directly.
- Four listing types. For sale, new builds, for rent and sold, each returning the fields specific to that type.
- Search-page data, no detail-page visits needed. Agents, offices, schools, open homes, floor plans and auction details all come straight from the search results.
- Structured output. Prices parsed into numeric values, addresses split into region, district and suburb, and GPS coordinates on every record.
- Resumable by design. A same-run checkpoint survives platform restarts automatically, and a separate run ID resume can continue one earlier interrupted crawl.
- Built for schedules. Incremental mode reports only new, updated, unchanged, expired or reappeared listings on repeat runs, so monitoring a search over time doesn't need its own diffing logic.
Choose what to collect
These inputs let you configure Realestate.co.nz Scraper - NZ Properties, Sales & Rentals. Open the actor on Apify to enter your values and review the current options.
| Input | What it controls |
|---|---|
modestring · required | Location mode = build URLs from region/district/suburb + filters below. URL mode = paste realestate.co.nz search result page URLs directly. |
locationsarray | Locations to search. Region, district, and suburb are all optional - provide whichever you have. Empty entries are dropped at runtime. |
listingTypestring | Type of property listings to scrape. In URL mode this is auto-detected from the URL. Sold returns historical sales data (sale prices, council valuations, estimated values). New Builds filters for new construction only. |
propertyTypesarray | Filter by property type. Leave empty for all types. |
priceMininteger | Minimum property price in NZD. |
priceMaxinteger | Maximum property price in NZD. |
bedroomsMininteger | Minimum number of bedrooms. |
Show 17 more inputs
| Input | What it controls |
|---|---|
bathroomsMininteger | Minimum number of bathrooms. |
includeNeighbouringSuburbsboolean | Include properties from neighbouring suburbs in results. When unchecked, only the exact suburb is searched. Most useful when searching at suburb level. |
sortstring | Sort order for search results. For Sold listings, 'latest' uses 'latest-sale' ordering automatically. |
maxPagesinteger | Maximum search result pages per location. Each page has ~20 results. When left empty, a built-in limit of 100 pages per location applies. |
urlsarray | Paste realestate.co.nz search result page URLs (sale, rental or sold; region, district, suburb, property-type, paginated, filtered, map-view, legacy lct= and non-www forms all work). Each URL is read as a single page - no pagination. Single-property detail pages and the /agents directory are not scraped: they are skipped with a warning in the run log. Left untouched, this field scrapes one example of each supported shape. |
maxListingsinteger | Stop after scraping this many listings. Leave empty for no limit. |
outputFormatarray | Export data in these formats |
resumeFromCheckpointboolean | Continue from the last saved checkpoint within the SAME run if it was interrupted (platform migration or a manual Resurrect). Distinct from resumeFromRunId (continues a specific PREVIOUS run by id) and incrementalMode (remembers this search across scheduled runs) below. |
resumeFromRunIdstring | Paste a previous run ID (or its dataset ID) to continue ONE interrupted crawl, listing ids already collected in that run are skipped so this run only adds new ones. For a same-run interruption use resumeFromCheckpoint instead; for ongoing scheduled monitoring of this search use incrementalMode below. |
incrementalModeboolean | Turn on when you run this same search on a schedule (e.g. daily) and only want to know what's new or changed since last time. The actor remembers this search's listings itself, no need to paste a run ID. Adds changeType (NEW/UPDATED/UNCHANGED/REAPPEARED/EXPIRED), changedFields, firstSeenAt, and lastSeenAt to every row. A listing is UPDATED when any output field differs from the stored copy (price, status, address, features, description, photos, agents, open homes, and so on); these never count as a change: the scrape timestamp (source), the featured/showcased placement flags (isFeatured, isShowcased), each agent's listingCount, and the ORDER of openHomes. Those fields are still in every row. You can exclude more with Ignore fields when detecting changes below. Off by default so existing scheduled runs are unaffected. See stateKey, emitUnchanged, and emitExpired below. |
stateKeystring | Optional label for the incrementalMode baseline. Leave empty to auto-derive one from your search settings (mode/locations/listingType/property types/price/bedrooms/bathrooms/neighbouring suburbs/sort/urls), a different filter setup automatically gets its own baseline, never sharing one by accident. Set this only if you want multiple differently-configured runs to intentionally share one baseline. |
emitUnchangedboolean | When incrementalMode is on, also output listings that are UNCHANGED since the last run (changeType=UNCHANGED, changedFields=[]). Off by default: unchanged listings are silently skipped, so you only see and pay for what's new or different. Turning this on bills extra dataset-item rows for listings that haven't changed. |
emitExpiredboolean | When incrementalMode is on, also output a row for previously-tracked listings that are no longer found (changeType=EXPIRED), so you can detect delistings. Only emitted after a run that scans the full tracked search with no cap hit and no resumeFromRunId, a partial run never marks a still-live listing as expired. Off by default. Turning this on bills extra dataset-item rows. |
ignoreFieldsForChangesarray | Incremental mode only. Field names that must NOT make a listing count as UPDATED, one per entry, e.g. photos or agents.phone. Use a dot for a nested field (price.display) and [] to reach every element of a list (agents[].email). The fields stay in the output rows; they are only left out of the comparison and out of changedFields. Already ignored by default: source, isFeatured, isShowcased, agents[].listingCount, and the order of openHomes. Changing this list does not cause a one-time wave of UPDATED rows. |
mcpConnectorsarray | Optionally send the scraped results into the apps you already use, via Model Context Protocol (MCP) connectors. Authorize a connector once under Apify → Settings → Integrations, then select it here. Notion gets a page per item; other connectors receive a best-effort write/digest. Leave empty to skip, this never changes the dataset output. Supported: Notion (https://mcp.notion.com/mcp), Linear (https://mcp.linear.app/sse), Airtable (https://mcp.airtable.com/mcp), Apify (https://mcp.apify.com). |
notionParentPageUrlstring | URL (or id) of the Notion page under which item pages are created. Required to enable the Notion export; ignored by other connectors. |
maxNotifyListingsinteger | Cap on items written to each connector per run. Does not affect the dataset. |
Fields in the output
The documented dataset includes the fields below. Availability can depend on the source page and selected mode.
changeTypeChange (text)changedFieldsChanged Fields (array)firstSeenAtFirst Seen (date)lastSeenAtLast Seen (date)idID (text)listingUrlURL (link)pricePrice (object)listingTypeType (text)propertyTypeProperty (text)addressAddress (object)featuresFeatures (object)statusStatus (text)Show 9 more fields
imagesImages (object)floorPlansFloor Plans (object)heroImageUrlHero Image (text)agentsAgents (object)officeOffice (object)locationCoordinates (object)schoolsSchools (object)auctionDateAuction (text)publishedDatePublished (text)Example output
An example from this actor’s documentation. Values are illustrative; this is not a fresh live result.
{
"id": "42993480",
"listingUrl": "https://www.realestate.co.nz/42993480/residential/sale/10-example-street-khandallah",
"listingNo": "ABC123XYZ",
"address": {
"full": "10 Example Street, Khandallah, Wellington City, Wellington",
"displayAddress": "10 Example Street, Khandallah",
"streetNumber": "10",
"streetName": "Example Street",
"suburb": "Khandallah",
"district": "Wellington City",
"region": "Wellington",
"postcode": "6035",
"country": "New Zealand",
"countryCode": "NZ"
},
"price": {
"display": "Buyer Enquiry Over $850,000",
"value": 850000,
"currency": "NZD",
"priceType": "enquiry_over"
},
"features": {
"bedrooms": 3,
"bathrooms": 2,
"garages": 1,
"landSizeInSqm": 350,
"floorAreaInSqm": 130
},
"propertyType": "house",
"sourcePropertyType": "House",
"listingType": "buy",
"listingCategoryCode": "res_sale",
"status": "active",
"heading": "Charming Family Home with Views",
"images": [
{
"url": "https://images.realestate.co.nz/listings/42993480/abc123.crop.140x178.jpg",
"thumbnailUrl": "https://images.realestate.co.nz/listings/42993480/abc123.crop.70x89.jpg",
"order": 1
}
],
"agents": [
{
"id": "100001",
"firstName": "Jane",
"lastName": "Smith",
"name": "Jane Smith",
"phone": "027 123 4567",
"email": "jane@example.co.nz",
"listingCount": 15
}
],
"office": {
"id": "5001",
"name": "Example Realty Ltd",
"colloquialName": "Example Realty",
"phone": "04 123 4567",
"email": "info@example.co.nz"
},
"location": {
"lat": -41.25,
"lon": 174.78
},
"schools": [
{
"name": "Sample Primary School",
"inZone": true,
"distance": "0.5km"
}
],
"openHomes": [],
"auctionDate": "2026-03-15T12:00:00+13:00",
"auctionLocation": "On site",
"publishedDate": "2026-02-26T17:55:27+13:00",
"isFeatured": false,
"isNewConstruction": false,
"source": {
"portal": "realestate.co.nz",
"scrapedAt": "2026-02-26T05:30:00.000Z"
}
}Ways to use this data
- Property portals and comparison sites: aggregate for sale, rental and new build listings from multiple NZ regions into one feed.
- Market research and appraisal: track sold prices, council valuations and estimated values to follow a suburb's price trend over time.
- Agencies and agents: monitor competing listings, prices, and agent or office details in a target area.
- Investors and buyers: filter by price, bedrooms and bathrooms, and get notified about new or changed listings on a schedule.
- Data teams and researchers: build a historical dataset of NZ property prices, features and locations.
Before you run
Start with a small input and check the resulting records against your expected fields. Source content and actor options can change; the current Apify listing is the reference for availability and pricing.
Questions about this actor
What data does Realestate.co.nz Scraper return?
The documented output for Realestate.co.nz Scraper includes change, changed fields, first seen, last seen, id, url, price and type. Availability of each field depends on the source page and the selected mode.
How much does Realestate.co.nz Scraper cost?
It costs $1.80 per 1,000 results on the Apify Free plan and from $1.00 on paid plans, with smaller per-run or optional feature charges listed on Apify. The Apify listing shows the current rate for every plan.
Can I get only new or changed listings on a schedule?
Yes. Schedule the actor from the Schedules tab and turn on Incremental mode. Each run then reports every listing as NEW, UPDATED, UNCHANGED, EXPIRED or REAPPEARED, and UNCHANGED rows are not output or billed unless you also turn on Emit unchanged listings.
What's the difference between Resume from checkpoint, Resume from run ID, and Incremental mode?
Resume from checkpoint only continues the same run after a platform interruption, with nothing to configure. Resume from run ID continues one specific earlier run by pasting its run or dataset ID. Incremental mode is for scheduling the same search repeatedly and remembers it on its own, keyed by a state key, with no ID to paste. They solve different problems and can be combined once, to bootstrap an incremental baseline from an existing run.
Why did my run fail instead of returning an empty dataset?
The run fails when zero listings were read and at least one result page failed to load or could not be parsed, when the input is invalid or contradictory (for example, pointing resumeFromRunId at an Incremental mode state that already has tracked listings, or at a run or dataset ID your account can't read), or when an unexpected error stops the scan. A search that loads correctly but genuinely matches nothing still succeeds, with zero rows and a status message on the run.
Can I use it with AI agents or MCP?
Yes. Call it from any Apify integration or MCP client, and use the connector field to push results into Notion, Linear or Airtable once the scrape finishes.
