🏠 Zillow Scraper - Listing Change Ledger & Coverage Monitor

Zillow Scraper - Listing Change Ledger & Coverage Monitor extracts structured Zillow property data and helps you track what changed, where it was observed, and whether the scan was complete enough to trust.

Use it for property research, listing monitoring, CRM automation, PropTech workflows, ETL pipelines, and change detection without manually revisiting Zillow pages.

• 🏠 Scrape Zillow listings: collect ZPIDs, addresses, prices, beds, baths, square footage, property type, coordinates, and more
• 🔎 Search by location or Zillow URL: use cities, ZIP codes, neighborhoods, direct Zillow search URLs, property URLs, or ZPIDs
• 🧬 Deduplicate by ZPID: reconcile overlapping observations into one canonical property record
• 🧭 Preserve provenance: keep the searches and search URLs that observed each property
• 📉 Track listing changes: detect new listings, price cuts, price increases, status changes, reactivations, and absence signals
• 🛡 Avoid false removals: blocked, capped, or incomplete scans are not silently treated as confirmed removals
• 📊 Measure scan quality: receive coverage diagnostics showing caps, failures, blocks, unique ZPIDs, duplicates, and detail success
• ⚡ Automate workflows: export structured results through Apify Dataset, API, integrations, or downstream applications

---

📦 What data does Zillow Scraper extract?

🆔 ZPID	🔗 Canonical Zillow URL
🏠 Address	🏷 Listing status
💵 Price	🛏 Beds
🛁 Baths	📐 Square feet
🏘 Property type	📈 Zestimate when available
📍 Latitude & longitude	🕒 Scrape timestamp
🔎 Source query	🌐 Source URL
🧭 Matched queries	🔗 Matched search URLs
🥇 First discovery query	🧹 Duplicate observation count
✅ Data consistency status	⚠️ Conflict evidence
🔬 Detail enrichment status	📊 Coverage diagnostics
🔄 Change events	🧬 Lifecycle summaries

Missing fields may be returned as null. The Actor does not invent property data that Zillow does not expose.

---

🚀 Features

Zillow Scraper is designed for auditable property extraction and change monitoring.

• Multiple discovery modes: locations, Zillow search URLs, property URLs, and ZPIDs
• Canonical ZPID reconciliation: use stable Zillow property IDs as the primary identity
• Overlapping-query provenance: preserve every query and search URL that observed a property
• Conflict detection: retain material disagreements instead of silently hiding conflicting values
• Coverage diagnostics: report whether each discovery scope was complete, partial, blocked, capped, or unknown
• False-removal protection: incomplete scans do not create fake confirmed-removal events
• Listing lifecycle tracking: retain first seen, last seen, observation counts, price-cut totals, pending transitions, and reactivations
• Change-event output: emit explicit machine-readable events with previous/current values and evidence
• Selective detail enrichment: fetch property details for all listings or only when they are new, changed, or insufficient
• Per-search and global limits: control maximum accepted listing observations
• Retry handling: retry temporary request failures according to your configuration
• Concurrent discovery: process independent search targets in parallel
• API-friendly output: every Dataset row uses a predictable recordType
• Browser-backed Zillow transport: designed for live Zillow pages and current Zillow response structures

---

⬇️ Input

You can configure Zillow Scraper directly from the Apify Console or send input programmatically through the Apify API.

You can combine multiple input types in one run.

---

📍 Locations

Use locations for Zillow location searches.

Examples:

Austin, TX
Miami, FL
90210
Downtown Los Angeles, CA

Example:

{
  "locations": [
    "Austin, TX",
    "Miami, FL"
  ]
}

Each location becomes its own discovery scope with its own coverage evidence.

---

🌐 Zillow search URLs

Use searchUrls when you already have a Zillow search page.

Example:

{
  "searchUrls": [
    "https://www.zillow.com/austin-tx/"
  ]
}

The Actor keeps the search URL as provenance and applies supported Actor filters when configured.

---

🏠 Direct property URLs

Use propertyUrls to scrape specific public Zillow property pages.

Example:

{
  "propertyUrls": [
    "https://www.zillow.com/homedetails/example-property/123456789_zpid/"
  ]
}

Direct property inputs are validated against the embedded ZPID when available.

---

🆔 ZPIDs

Use zpids when you already know the Zillow property IDs.

Example:

{
  "zpids": [
    "123456789",
    "987654321"
  ]
}

ZPIDs are treated as stable property identities for reconciliation and monitoring.

---

🔢 Maximum items per search

maxItemsPerLocation controls the maximum accepted listing observations from each location or Zillow search URL.

Minimum: 1
Default: 1000
Maximum: 5000

If the limit is reached before completeness can be proven, the search is reported as:

coverageStatus: CAPPED

with a transparent reason such as:

USER_TOTAL_LIMIT_REACHED

---

🌍 Maximum total items

maxTotalItems limits accepted observations across all direct targets and searches in the run.

Minimum: 1
Default: 5000
Maximum: 50000

This is a maximum, not a guarantee.

If Zillow exposes fewer usable listings, the Actor returns the listings it can verify instead of fabricating rows.

---

🎛 Listing filters

🏷 Listing status

Supported listingStatus values:

for_sale
for_rent
sold
pending
any

any preserves the URL/default status state instead of forcing a specific supported status filter.

Default:

for_sale

---

🏘 Property types

Supported propertyTypes values:

SINGLE_FAMILY
CONDO
TOWNHOUSE
MULTI_FAMILY
APARTMENT
MANUFACTURED
LOT

Example:

{
  "propertyTypes": [
    "SINGLE_FAMILY",
    "CONDO"
  ]
}

---

💵 Price filters

Optional inputs:

minPrice
maxPrice

Example:

{
  "minPrice": 300000,
  "maxPrice": 900000
}

---

🛏 Bed and bath filters

Optional inputs:

minBeds
maxBeds
minBaths

Example:

{
  "minBeds": 3,
  "maxBeds": 5,
  "minBaths": 2
}

---

🔬 Detail enrichment

Set:

includeDetails: true

to allow Zillow property-detail requests.

Supported detailStrategy values:

none
all
new_or_changed_only

Default:

new_or_changed_only

none

Skip detail enrichment.

all

Attempt detail enrichment for every canonical property, subject to maxDetailFetches.

new_or_changed_only

Use detail requests selectively for records that are new, changed, conflicting, or missing useful information.

This can reduce unnecessary requests during recurring monitor runs.

---

🔢 Maximum detail fetches

maxDetailFetches limits the number of property-detail requests in one run.

Minimum: 0
Default: 250
Maximum: 5000

Coverage output reports:

detailRequested
detailSucceeded
detailSuccessRate

so downstream systems can see how much enrichment actually succeeded.

---

🧹 ZPID deduplication

By default:

deduplicateByZpid: true

The Actor reconciles multiple observations of the same ZPID into one canonical CURRENT record.

This is useful when the same property appears in:

Austin, TX
+
78747
+
a Zillow search URL

Instead of blindly returning duplicate properties, the Actor can preserve the overlap as provenance.

---

🧭 Matched-query provenance

When:

preserveMatchedQueries: true

the canonical property can include:

{
  "matchedQueries": [
    "Austin, TX",
    "78747"
  ],
  "matchedSearchUrls": [
    "https://www.zillow.com/austin-tx/",
    "https://www.zillow.com/..."
  ]
}

This answers an important question:

Which discovery scopes actually observed this ZPID?

That provenance is especially useful for ETL, CRM routing, data QA, and monitoring systems.

---

⚠️ Cross-source conflicts

If material observations disagree, the Actor can preserve the disagreement instead of silently choosing a value.

Example:

{
  "dataStatus": "CONFLICT",
  "conflicts": [
    {
      "field": "price",
      "values": [
        500000,
        525000
      ]
    }
  ]
}

Possible dataStatus values:

CONSISTENT
CONFLICT
PARTIAL

This makes conflicting source evidence visible to downstream automation.

---

📊 Coverage diagnostics

Enable:

includeCoverageReport: true

to receive COVERAGE records for discovery scopes.

Coverage can include:

rawRows
uniqueZpids
duplicatesRemoved
reportedMatches
pagesScanned
partitionsScanned
requestsSucceeded
requestsFailed
detailRequested
detailSucceeded
detailSuccessRate
capHit
blockedRequests
coverageStatus
coverageReasons
checkedAt

Supported coverageStatus values:

COMPLETE
PARTIAL
BLOCKED
CAPPED
UNKNOWN

---

🛡 Why coverage matters

A scraper should not treat:

0 results

as automatically meaning:

0 properties exist

A scan may instead be:

blocked
partially parsed
capped by a user limit
affected by a request failure
missing detail enrichment

Zillow Scraper exposes these conditions so automated systems can decide whether the output is safe to trust.

---

🔄 Monitoring changes across runs

Set:

monitorMode: true

and provide a stable:

monitorId

to compare the current run with persistent monitor state.

Example:

{
  "monitorMode": true,
  "monitorId": "austin-investment-watch"
}

Use the same monitorId on future runs to continue the same history.

---

🆕 First monitor run

When a property is seen for the first time, the Actor can emit:

changeType: NEW

The lifecycle state begins with:

firstSeenAt
lastSeenAt
observationsCount
lifecycleStage

---

🔁 Later monitor runs

If a property is observed again with no material change:

No new CHANGE_EVENT is required

but its lifecycle state can still update:

lastSeenAt
observationsCount

If something materially changes, the Actor can emit an evidence-backed change event.

---

🔔 Change-event types

Supported changeType values include:

NEW
PRICE_CUT
PRICE_INCREASE
STATUS_CHANGED
ACTIVE_AGAIN
NOT_SEEN_CONFIRMED
NOT_SEEN_PARTIAL_SCAN
DATA_CONFLICT

Each CHANGE_EVENT can contain:

changedFields
previousValues
currentValues
detectedAt
previousObservedAt
currentObservedAt
priceChange
priceChangePercent
observationConfidence
evidence
reasonCodes

---

📉 Price changes

Example:

{
  "recordType": "CHANGE_EVENT",
  "zpid": "123456789",
  "changeType": "PRICE_CUT",
  "changedFields": [
    "price"
  ],
  "previousValues": {
    "price": 650000
  },
  "currentValues": {
    "price": 625000
  },
  "priceChange": -25000
}

Lifecycle output can retain:

numberOfPriceCuts
cumulativePriceCut
cumulativePriceCutPercent

---

🏷 Status changes

The Actor can track status transitions such as:

FOR_SALE → PENDING
PENDING → FOR_SALE

Lifecycle output can retain:

wentPendingCount
backOnMarketCount
statusTransitions

when event-history retention is enabled.

---

🛡 False-removal protection

One of the most important monitoring rules is:

An incomplete Zillow scan must not be treated as proof that a property disappeared.

If a previously observed property is missing from a run, the Actor evaluates the scan evidence first.

✅ Confirmed absence

When the required discovery coverage is reliable enough, the Actor can emit:

NOT_SEEN_CONFIRMED

⚠️ Incomplete scan

When the search was blocked, capped, failed, or otherwise incomplete, the Actor can emit:

NOT_SEEN_PARTIAL_SCAN

instead of silently declaring the property removed.

The retained monitor state is protected from fake disappearance signals caused by bad scans.

---

🧬 Lifecycle records

In monitor mode, the Actor can emit LIFECYCLE records such as:

{
  "recordType": "LIFECYCLE",
  "zpid": "123456789",
  "firstSeenAt": "2026-09-01T00:00:00.000Z",
  "lastSeenAt": "2026-09-11T00:00:00.000Z",
  "observationsCount": 6,
  "numberOfPriceCuts": 2,
  "cumulativePriceCut": -35000,
  "wentPendingCount": 1,
  "backOnMarketCount": 1,
  "lifecycleStage": "FOR_SALE",
  "statusTransitions": []
}

This provides a compact history summary without requiring you to reconstruct every state transition manually.

---

📜 Retain lifecycle history

Set:

retainEventHistory: true

to retain supported lifecycle status-transition history in persistent monitor state.

The current version does not create a separate historical-event Dataset for every previous observation.

---

🎯 Emit only changes

Set:

emitOnlyChanges: true

when you primarily want change events during monitoring.

In this mode, normal CURRENT and LIFECYCLE rows can be omitted from public output while requested coverage diagnostics remain available.

This is useful for:

webhooks
CRM triggers
alerts
scheduled monitors
change-only ETL jobs

---

🌐 Proxy configuration

Zillow can return temporary blocks or interactive challenges.

You can provide an Apify proxyConfiguration when needed.

Example:

{
  "proxyConfiguration": {
    "groups": [
      "UNBLOCKER"
    ]
  }
}

The Actor does not pretend that a blocked page is a successful empty result.

Blocked requests are reported through coverage and error diagnostics such as:

blockedRequests
coverageStatus: BLOCKED
errorCode: BLOCKED

The Actor is designed to work with public Zillow pages. It does not bypass interactive CAPTCHA or human-verification challenges.

---

⚙️ Reliability controls

🚀 Maximum concurrency

maxConcurrency controls how many independent search targets can be collected concurrently.

Minimum: 1
Default: 8
Maximum: 50

---

🔁 Maximum retries

maxRetries controls retry attempts for retryable Zillow failures.

Minimum: 0
Default: 3
Maximum: 10

---

⏱ Request delay

requestDelayMs controls the base delay used around throttled/retry requests.

Minimum: 0 ms
Default: 250 ms
Maximum: 30000 ms

---

🧪 Example input

{
  "locations": [
    "Austin, TX"
  ],
  "searchUrls": [],
  "propertyUrls": [],
  "zpids": [],
  "maxItemsPerLocation": 100,
  "maxTotalItems": 500,
  "listingStatus": "for_sale",
  "propertyTypes": [
    "SINGLE_FAMILY",
    "CONDO"
  ],
  "minPrice": 300000,
  "maxPrice": 900000,
  "minBeds": 3,
  "minBaths": 2,
  "includeDetails": true,
  "detailStrategy": "new_or_changed_only",
  "maxDetailFetches": 100,
  "deduplicateByZpid": true,
  "preserveMatchedQueries": true,
  "includeCoverageReport": true,
  "monitorMode": true,
  "monitorId": "austin-homes-watch",
  "emitOnlyChanges": false,
  "retainEventHistory": true,
  "proxyConfiguration": {
    "groups": [
      "UNBLOCKER"
    ]
  },
  "maxConcurrency": 4,
  "maxRetries": 3,
  "requestDelayMs": 250
}

---

⬆️ Output

Results are stored in the Actor's default Apify Dataset.

You can access them through:

Output
Storage
Apify API
Integrations

The Dataset can contain five record types:

CURRENT
CHANGE_EVENT
LIFECYCLE
COVERAGE
ERROR

Use the recordType field to route each row in downstream workflows.

---

🏠 Example CURRENT record

{
  "recordType": "CURRENT",
  "zpid": "123456789",
  "canonicalUrl": "https://www.zillow.com/homedetails/123456789_zpid/",
  "address": "123 Example St, Austin, TX 78701",
  "status": "FOR_SALE",
  "price": 625000,
  "beds": 3,
  "baths": 2,
  "sqft": 1800,
  "propertyType": "SINGLE_FAMILY",
  "zestimate": null,
  "latitude": 30.2672,
  "longitude": -97.7431,
  "scrapedAt": "2026-09-11T00:00:00.000Z",
  "sourceQuery": "Austin, TX",
  "sourceUrl": "https://www.zillow.com/austin-tx/",
  "matchedQueries": [
    "Austin, TX"
  ],
  "matchedSearchUrls": [
    "https://www.zillow.com/austin-tx/"
  ],
  "firstDiscoveredByQuery": "Austin, TX",
  "duplicateObservationCount": 0,
  "dataStatus": "CONSISTENT",
  "conflicts": [],
  "detailFetched": true,
  "detailStatus": "SUCCESS"
}

---

📊 Example COVERAGE record

{
  "recordType": "COVERAGE",
  "queryKey": "location:austin-tx",
  "query": "Austin, TX",
  "searchUrl": "https://www.zillow.com/austin-tx/",
  "rawRows": 41,
  "uniqueZpids": 41,
  "duplicatesRemoved": 0,
  "reportedMatches": null,
  "pagesScanned": 1,
  "partitionsScanned": 1,
  "requestsSucceeded": 2,
  "requestsFailed": 0,
  "detailRequested": 0,
  "detailSucceeded": 0,
  "detailSuccessRate": null,
  "capHit": true,
  "blockedRequests": 0,
  "coverageStatus": "CAPPED",
  "coverageReasons": [
    "USER_TOTAL_LIMIT_REACHED"
  ],
  "checkedAt": "2026-09-11T00:00:00.000Z"
}

A CAPPED scan is not treated as secretly complete.

---

🔄 Example CHANGE_EVENT record

{
  "recordType": "CHANGE_EVENT",
  "zpid": "123456789",
  "changeType": "STATUS_CHANGED",
  "changedFields": [
    "status"
  ],
  "previousValues": {
    "status": "FOR_SALE"
  },
  "currentValues": {
    "status": "PENDING"
  },
  "detectedAt": "2026-09-11T00:00:00.000Z",
  "previousObservedAt": "2026-09-10T00:00:00.000Z",
  "currentObservedAt": "2026-09-11T00:00:00.000Z",
  "priceChange": null,
  "priceChangePercent": null,
  "observationConfidence": "HIGH",
  "evidence": {
    "searchSucceeded": true,
    "detailSucceeded": true,
    "coverageStatus": "COMPLETE"
  },
  "reasonCodes": []
}

---

❌ Example ERROR record

Errors are explicit Dataset records rather than silent empty results.

Example:

{
  "recordType": "ERROR",
  "errorCode": "PARTIAL_COVERAGE",
  "message": "Discovery scope could not be proven complete.",
  "queryKey": "location:austin-tx",
  "sourceUrl": "https://www.zillow.com/austin-tx/",
  "retryable": true,
  "createdAt": "2026-09-11T00:00:00.000Z"
}

Supported diagnostic codes include:

INVALID_INPUT
REQUEST_FAILED
BLOCKED
PARSE_FAILED
DETAIL_FAILED
SEARCH_CAPPED
PARTIAL_COVERAGE
DATA_CONFLICT

---

👀 Dataset views

The Dataset schema includes dedicated views for different workflows.

🏠 Listing ledger overview

Focuses on:

record type
ZPID
address
status
price
change type
data status
coverage status
confidence
source
timestamps

🔄 Monitoring evidence

Focuses on:

change events
previous/current values
price deltas
first/last seen
price-cut totals
pending/reactivation counts
lifecycle stage

🛡 Coverage & quality

Focuses on:

coverage status
coverage reasons
raw rows
unique ZPIDs
duplicates
request success/failure
blocks
detail success
conflicts
errors

---

⚡ Performance

The Actor uses browser-backed Zillow requests designed for current public Zillow page structures.

Performance depends on:

Number of search targets
Result limits
Detail strategy
Maximum detail fetches
Proxy configuration
Zillow response time
Concurrency
Retry settings

For lower cost and faster recurring monitors, consider:

detailStrategy: new_or_changed_only

instead of fetching full details for every unchanged property on every run.

---

🛡 Reliability

Zillow Scraper is designed to make failure states visible.

If one discovery scope fails while others succeed, successful data can still remain available with explicit coverage diagnostics for the affected scope.

The Actor distinguishes conditions such as:

COMPLETE
PARTIAL
BLOCKED
CAPPED
UNKNOWN

instead of collapsing every condition into a successful empty Dataset.

This is especially important when the output is consumed automatically.

---

🔌 API & integrations

Zillow Scraper can be used programmatically through the Apify API.

You can connect Dataset results to workflows such as:

• Google Sheets
• Make
• Zapier
• CRMs
• Internal APIs
• Data warehouses
• Property-analysis pipelines
• Lead and acquisition systems
• AI agents
• MCP workflows

Every run stores structured output in the default Dataset, making the results easy to consume from another application.

---

💡 Example use cases

🏠 Property listing research

Search one or more markets and collect:

ZPID
Address
Status
Price
Beds
Baths
Square feet
Property type
Coordinates
Source query

Use the results for property analysis, market research, or internal data pipelines.

---

📉 Price-change monitoring

Schedule the Actor with:

monitorMode: true
monitorId: your-stable-monitor-id

to identify:

New listings
Price cuts
Price increases
Status changes
Back-on-market events

without manually comparing Zillow pages.

---

📊 Data-quality monitoring

Use COVERAGE records to determine:

Was the search complete?
Was the run capped?
Were requests blocked?
How many unique ZPIDs were found?
How many detail requests succeeded?

This is useful before feeding Zillow data into automated decisions.

---

🧭 Multi-query reconciliation

Run overlapping searches such as:

Austin, TX
78747
South Austin, TX

and use ZPID reconciliation plus matched-query provenance to see which properties overlap across scopes.

---

⚙️ CRM and automation triggers

With:

emitOnlyChanges: true

monitor runs can focus on machine-readable change events suitable for downstream alerts and workflows.

---

⚠️ Current limitations

The current version focuses on public Zillow listing discovery, reconciliation, coverage diagnostics, and monitoring.

Important limitations:

Zillow may expose fewer results than requested
Some public fields may be null
Search completeness depends on Zillow response behavior and configured limits
Interactive challenges can still block a request
A blocked or partial scan is not automatically treated as a confirmed removal
V1 normally uses one partition per input search
Lifecycle state does not create a separate historical Dataset for every prior observation

The Actor does not:

Log into private Zillow accounts
Scrape private/account-only property data
Bypass interactive CAPTCHA or human-verification challenges
Invent missing fields
Pretend incomplete scans are complete

---

❓ FAQ

How does Zillow Scraper work?

The Actor accepts locations, search URLs, property URLs, or ZPIDs.

It then:

Builds discovery targets
Fetches public Zillow pages
Parses Zillow search/property data
Normalizes property observations
Reconciles by ZPID
Preserves matched-query provenance
Optionally enriches property details
Calculates coverage diagnostics
Compares persistent monitor state when enabled
Emits Dataset records

---

Can I scrape multiple locations in one run?

Yes.

Add multiple values to:

locations

Each location is treated as its own discovery scope.

---

Can I provide Zillow search URLs directly?

Yes.

Use:

searchUrls

This is useful when you already have a specific Zillow search page you want to process.

---

Can I scrape one property directly?

Yes.

Use either:

propertyUrls

or:

zpids

Direct targets receive their own coverage evidence.

---

Why is the canonical URL sometimes shorter than the original Zillow URL?

The Actor reconciles property identity around the ZPID.

A normalized canonical URL can therefore look like:

https://www.zillow.com/homedetails/123456789_zpid/

while sourceUrl preserves the actual page used as evidence.

---

Why are some fields null?

Zillow does not expose every field consistently for every property or response type.

The Actor deliberately uses:

null

when a value is unavailable instead of fabricating data.

---

What does CAPPED mean?

CAPPED means the configured item limit was reached before the Actor could prove that the discovery scope was fully exhausted.

Example:

Zillow exposed 41 unique ZPIDs
maxTotalItems was 25

The Actor can return 25 records while clearly reporting:

coverageStatus: CAPPED

This is intentional.

---

What does PARTIAL mean?

PARTIAL means the Actor obtained some evidence but could not prove complete coverage.

Possible causes can include:

Request failure
Parse failure
Incomplete detail enrichment
Other incomplete discovery evidence

Check:

coverageReasons

for the exact reason.

---

What happens if Zillow blocks a request?

The Actor records the block explicitly.

Depending on the affected scope, you may see:

blockedRequests > 0
coverageStatus: BLOCKED
errorCode: BLOCKED

The Actor does not silently convert a blocked page into zero listings.

---

How does monitoring avoid false removals?

The Actor checks coverage evidence before treating a missing property as confirmed absent.

Reliable coverage can produce:

NOT_SEEN_CONFIRMED

Incomplete coverage can produce:

NOT_SEEN_PARTIAL_SCAN

This prevents a blocked, capped, or failed scan from automatically becoming a fake removal event.

---

What should I use as monitorId?

Use a stable name that identifies the monitoring job.

Examples:

austin-homes-watch
phoenix-rentals-monitor
client-42-acquisition-list

Reuse the same ID on future runs to continue the same monitor history.

---

Can I output only changes?

Yes.

Use:

emitOnlyChanges: true

This is useful for recurring automations where unchanged CURRENT rows are not needed.

---

Can I export the results?

Yes.

Apify Dataset results can be exported in supported formats such as:

JSON
CSV
Excel
XML
HTML

---

Can I use the Actor through an API?

Yes.

Every Actor run can be started through the Apify API, and Dataset results can be retrieved programmatically.

This makes Zillow Scraper suitable for ETL, CRM, monitoring, and automation pipelines.

---

🧭 Recommended workflow

For normal one-time property discovery:

1. Add locations or Zillow search URLs
2. Set your item limits
3. Choose listing filters
4. Enable coverage diagnostics
5. Use selective detail enrichment when needed
6. Run the Actor
7. Review CURRENT and COVERAGE records

For recurring monitoring:

1. Create a stable monitorId
2. Keep the same discovery inputs across runs
3. Enable monitorMode
4. Keep coverage diagnostics enabled
5. Use new_or_changed_only detail strategy
6. Schedule recurring Actor runs
7. Route CHANGE_EVENT records to alerts or automation

For stronger trust:

Do not rely only on listing rows
+
Check COVERAGE records
+
Review DATA_CONFLICT events
+
Treat CAPPED/PARTIAL/BLOCKED scopes differently from COMPLETE scopes

---

💬 Feedback & support

Found a bug or have a feature request?

Use the Actor's Issues tab on Apify.

Useful future additions may include:

More advanced partitioning for very large markets
Additional lifecycle analytics
More selective enrichment strategies
Dedicated historical event storage
Additional Zillow public fields
More market-level monitoring summaries

---

🚀 Zillow listing data you can audit

Enter locations, Zillow URLs, or ZPIDs, run the Actor, and receive structured Zillow property data with ZPID reconciliation, listing-change events, lifecycle tracking, provenance, and coverage evidence ready for research, APIs, CRM workflows, ETL, and automation.