Realtor.com Property Search & Change Monitor

Collect public Realtor.com property data for research, lead lists, comparisons, and factual change monitoring. Start with a city, state-qualified place, ZIP code, public search URL, or exact public property URL; the safe default returns ten search-card rows.

The Actor collects only public first-party Realtor.com data. Login, private account data, CAPTCHA solving, and child Actors are excluded. Every run includes a free coverage row so a block, cap, filter, source drift, or confirmed empty result is never disguised as success.

🚀 Start in 60 seconds

1. Choose Search properties.
2. Enter a location such as Austin, TX.
3. Keep Search cards - fastest and the safe ten-property limit.
4. Run the Actor, then open the Properties and Coverage Dataset views.

{
  "workflow": "search_properties",
  "location": "Austin, TX",
  "listingStatus": "for_sale",
  "maxProperties": 10,
  "detailLevel": "search_cards"
}

🎯 Choose the right workflow

Workflow	Use it for	Verified boundary
Search properties	Build for-sale, rental, or sold-property datasets from a location.	Austin for-sale, for-rent, and sold search cards; one Austin for-sale search with full public details.
Collect exact property URLs	Enrich known public Realtor.com property URLs.	One exact Austin sale property completed all four declared public-detail groups. One public Austin rental community additionally exposed 5 floorplans and 24 unit-availability records through its anonymous first-party page data.
Monitor market or properties	Seed a baseline and compare later compatible snapshots.	One exact public property baseline and one unchanged repeat committed safely with zero false changes.
Find comparables	Compare fetched properties with source-backed reference values.	Two Austin candidates returned with deterministic arithmetic differences. No valuation is inferred.

The same source operation accepts location and ZIP inputs, but only the boundaries above are included in the verified product promise. Other markets and combinations remain source-dependent.

📦 What you get

Every row has a stable identity, row type, idempotent delivery ID, and source-contract version. Source-dependent property fields can include:

• listing and property IDs, canonical URL, status, dates, and currency;
• list, sold, original, and reduced-price values plus deterministic price per square foot;
• property type, beds, baths, living area, lot size, year built, stories, units, garage, HOA, and zoning;
• address, coordinates, description, features, flags, source metadata, and search placement;
• public photos, verified virtual tours, and video links;
• rental-community floorplans with names, beds, baths, square feet, advertised prices, images, availability, and nested public unit records when the verified rental-page contract publishes them;
• agents, advertisers, offices, schools, neighborhoods, history, tax, permit, and environmental-risk records when published;
• field-level provenance and detail-layer coverage instead of silently filled nulls.

Dataset row types are property, change, comparable, and coverage. Named views select useful columns while recordType remains visible.

The Actor does not estimate value, predict appreciation, recommend an investment, or assign a subjective score.

Real public rental-detail example

This compact row retains values returned by an anonymous exact-property run. Large arrays and nested objects are omitted for readability.

{
  "recordType": "property",
  "stableId": "realtor-property:7099312028",
  "deliveryId": "realtor-delivery:a676e2c091c467d5f41d3cdbe5df1d90090682fcd10c9dc0",
  "propertyId": "7099312028",
  "listingId": "2983804288",
  "status": "for_rent",
  "listPrice": null,
  "propertyType": "apartment",
  "yearBuilt": 1983,
  "units": 352,
  "address": {
    "line": "11411 Research Blvd",
    "city": "Austin",
    "stateCode": "TX",
    "postalCode": "78759",
    "country": "USA"
  },
  "rentalFloorplanCount": 5,
  "rentalUnitCount": 24,
  "sourceContractVersion": "realtor-public-first-party-v14",
  "detailCoverage": {
    "status": "COMPLETE",
    "completedLayers": [
      "property_details",
      "property_and_tax_history",
      "neighborhoods_and_schools",
      "environmental_risks",
      "rental_floorplans"
    ]
  }
}

🎛️ Input guide

Choose targets and depth

Parameter	What it changes	Coverage or cost effect
workflow	Selects search, exact-property, monitoring, or comparable output.	Changes the source work and billable event pair.
location	Sets the primary city/state or ZIP target.	The safe default creates one target.
additionalLocations	Adds more location targets.	Each location adds source work and its own target receipt.
listingStatus	Selects for_sale, for_rent, or sold.	Becomes part of the monitoring scope.
searchUrls	Uses public Realtor.com search URLs instead of generated location targets.	Each URL is a separate target.
propertyUrls	Supplies exact public Realtor.com sale-detail or rental-detail URLs.	Each property requests the bounded detail contract; rental community pages can add public floorplans and unit availability.
maxProperties	Caps property, change, or comparable rows.	Main output and cost ceiling: 5,000 search-card rows or 2,000 full-detail rows.
detailLevel	Chooses fast search cards or full public details.	Full details use four bounded public operations; a public rental page can add one floorplan layer.

Filter and order published values

Parameter	What it changes	Important behavior
propertyTypes	Keeps selected normalized property types.	Missing source values do not become invented types.
minPrice, maxPrice	Sets a published-price range.	Rental minimum price remains distinct from a single listing price.
minBeds, maxBeds	Sets the bedroom range.	Applied only to published counts.
minBaths, maxBaths	Sets the bathroom range.	Applied only to published counts.
minLivingAreaSqft, maxLivingAreaSqft	Sets the living-area range.	Uses normalized square feet.
minLotSizeSqft, maxLotSizeSqft	Sets the lot-size range.	Uses normalized square feet.
keywords	Requires terms in published address, description, or features.	Can produce FILTERED coverage.
sort	Preserves source order or sorts by date or price.	Sorting changes the monitoring scope fingerprint.

Monitoring, comparables, and guards

Parameter	What it changes	Important behavior
stateNamespace	Separates compatible monitoring histories.	Keep it stable across repeats of the same scope.
includeUnchanged	Adds current unchanged property rows.	Unchanged context is not billed as a change.
referenceProperty	Supplies source-backed comparable values.	Output is arithmetic difference, never a valuation or score.
maxBuyerChargeUsd	Checks the maximum possible buyer charge before source work and stops when the requested ceiling is too low.	Buyer-spend guard.
maxPagesPerTarget	Limits pagination per target.	Reaching it produces CAPPED, not false completion.
maxRequests	Limits all source requests in the run.	Stops before uncontrolled request growth.
maxSourceBytes	Limits accepted source bytes.	Stops transfer growth.
maxRuntimeSecs	Limits source-work time.	Stops long source loops.
maxEstimatedPlatformUsd	Limits estimated platform usage for the run.	Stops before the declared guard is exceeded.

💰 Pricing

run charge = verified search/comparable targets × target price + one verified exact-property batch gate when that workflow is used + delivered rows × row price

Delivered work	Unit price
Search/comparable target, or one exact-property batch	$0.0076
Monitoring target	$0.0040
Search-card property	$0.0012
Full-detail property	$0.00075
Comparable row	$0.0012
Change event	$0.0006

For one completed search target, ten search-card properties would be $0.0196; one exact-property batch with ten complete full-detail properties would be $0.0151 regardless of whether the batch contains one or several requested URLs; an unchanged monitoring scan would be $0.0040. Free coverage rows and incomplete detail rows do not add result charges. These values never override maxBuyerChargeUsd.

✅ Coverage you can trust

Status	Exact fleet meaning
COMPLETE	Every requested target completed inside declared limits.
PARTIAL	At least one target or required layer did not complete; returned rows are only the truthful completed portion.
FILTERED	Source work completed, but deterministic buyer filters removed rows.
CAPPED	A row, page, request, byte, runtime, or spend guard stopped full coverage.
BLOCKED	A positively identified challenge or access block stopped public-source collection.
FAILED	The response did not match the expected first-party contract or another unattributed failure occurred.
EMPTY_CONFIRMED	The expected first-party response explicitly confirmed zero matching properties.

Monitoring follows the shared fleet contract:

• the first run that reaches trustworthy coverage seeds a baseline without a false NEW flood;
• each repeat run must use the same targets, filters, order, limits, detail depth, and stateNamespace to remain comparable;
• UPDATED contains only exact normalized fields that changed;
• ENDED means only that a stable property identity was absent from two consecutive complete, comparable scans;
• ENDED never means deleted, sold, inactive, unavailable, or removed from Realtor.com;
• PARTIAL, FILTERED, CAPPED, BLOCKED, and FAILED runs never evaluate absence and never commit monitoring state;
• state commits only after atomic delivery is acknowledged, so a retry does not duplicate a paid row or event.

⚠️ Not yet supported

The product deliberately excludes anything outside the demonstrated supported scope:

• login-only, private, saved, personalized, or account data;
• CAPTCHA solving or continuation after a CAPTCHA;
• a guarantee that every Realtor.com market or every listing on the site is returned;
• floorplans or unit availability for every property: one public Austin rental community proved five floorplans and 24 units, while other properties may publish none;
• populated open-house rows: no live run has returned one;
• guaranteed beds, baths, or living area on every rental community card;
• a claim that a naturally occurring live NEW, UPDATED, or ENDED event has already been observed;
• treating disappearance from a bounded search window as deletion, sale, or unavailability;
• valuations, investment recommendations, popularity scores, sentiment, review analysis, or inferred contact data;
• a fixed source SLA: public source structures can change without notice.

🔌 API and automation

The Actor writes standard Apify Dataset and key-value-store output, so a released build can be called from the Apify API and connected to buyer-owned exports or automations. Public Tasks, schedules, webhooks, GitHub packages, n8n flows, and managed promotion are not yet included.

For monitoring, reuse the same input and stateNamespace. Changing targets, filters, ordering, limits, or detail depth creates a different scope fingerprint instead of mixing incompatible snapshots.

❓ FAQ and support

Does an empty Dataset prove there are no properties?

No. Read the free coverage row. Only EMPTY_CONFIRMED proves that the expected first-party response explicitly returned zero matching records.

Does ENDED mean sold or deleted?

No. It is a narrow observation after two complete comparable absences. Use the source-published listing status for business meaning.

Does the Actor log in or bypass protection?

No. Login is outside the product and CAPTCHA is a hard stop.

Are all listed fields guaranteed on every property?

No. Realtor.com publishes different fields by property and market. fieldCoverage, fieldProvenance, and detailCoverage show exactly what was present and which requested layers completed.

How should I report a problem?

Include the Actor run ID, input with secrets removed, coverage status, and the affected public target. Do not share credentials or private data.

Realtor.com and its marks belong to their owner. The bundled small icon is an unchanged official asset linked from Realtor.com's mobile page; it is not generated or redrawn. This independent Actor is not presented as endorsed by Realtor.com.