Redfin New Listing Monitor avatar

Redfin New Listing Monitor

Pricing

Pay per event

Go to Apify Store
Redfin New Listing Monitor

Redfin New Listing Monitor

Redfin scrapers give you a snapshot and forget it — you rebuild the diff yourself every time. This one remembers every listing it has already shown you for your search area and alerts only on genuinely new ones. No third-party browser account needed. A failed or blocked check is never billed.

Pricing

Pay per event

Rating

0.0

(0)

Developer

Radu Furtuna

Radu Furtuna

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

a day ago

Last modified

Share

Durable monitor for new for-sale listings appearing in a saved Redfin search area (city, zip code, county, or neighborhood), via a real remote browser. Pay only for genuinely new listings; checking an area with nothing new is free.

How it works

  1. No third-party account needed. Redfin blocks plain headless browsers, so a real anti-detect browser is required — this Actor uses a built-in stealth browser by default. You can still point it at your own remote browser (cdpUrl, e.g. a Bright Data Scraping Browser) if you prefer; the backend is never switched automatically, and whichever one is used is reported in the run's coverage.fetchBackend.
  2. Each watch is a saved Redfin search area URL (city/zip/county/neighborhood page).
  3. Every run reloads that search page and diffs the listings found against a durable checkpoint of listing IDs already seen for that watch.
  4. Genuinely new listings are pushed to the dataset and billed once each (new-listing-detected); checking an area with nothing new costs nothing beyond the fixed platform run cost.

Input

{
"monitorId": "my-search",
"watches": [
{ "watchId": "austin-tx", "searchUrl": "https://www.redfin.com/city/30818/TX/Austin" }
],
"notifyOn": "new_alerts",
"webhookUrl": "https://example.com/webhook"
}

Add more watches later under the same monitorId — each watch keeps its own independent history.

Billing

Two events:

  • target-check-confirmed — $0.015, charged once per successful check of a watch (including the baseline check), regardless of whether anything new was found.
  • new-listing-detected — $0.01, charged once per listing genuinely new since the previous check of that watch, on top of the check fee.

Failed and blocked checks are never charged — not the check fee, not anything else.

What a check actually costs you, in full

Reading Redfin requires driving a real anti-detect browser, and that browser run appears on your Apify bill, not ours. Measured on a live run of one watch:

line itemper check
this Actor's target-check-confirmed$0.015
built-in stealth browser (its own two events)$0.004
platform compute for that browser run~$0.036
total~$0.055

We would rather state this up front than let you discover it on an invoice. Two things worth knowing:

  • If you instead supply your own cdpUrl, you pay that provider directly for the same browser work — the cost does not disappear, it just moves off your Apify bill and onto theirs.
  • A check that fails or gets blocked still consumes the browser run it attempted. This Actor charges you nothing for it, but the browser time is real and is not refundable.

Delivery guarantee for new-listing-detected: at-most-once (not exactly-once)

The right to write a listing row and to charge new-listing-detected for it is granted by a single atomic primitive — one addRequest(uniqueKey) into a dedicated, named claim-journal Request Queue (<prefix>-<monitorId>-claims). Exactly one run ever wins that key. Claim requests are never deleted and never handled: the queue is a permanent journal of irreversible attempts, not a work list.

What this buys you, stated honestly:

  • You will never be charged twice for the same listing. That is the guarantee.
  • It is not exactly-once. If a run wins the claim and then dies before the row reaches the dataset (or before the charge completes), that listing is lost: it closes as dataset_unknown / charge_unknown and is never re-delivered. We deliberately prefer losing a delivery over double-charging you.
  • target-check-confirmed is deliberately outside this gate. It is not deduplicated between runs, because a repeated successful check is real work actually performed (a real Bright Data page load), not a duplicate of an earlier one. Only the per-listing event is claim-gated.
  • Boundary of the guarantee: it holds for as long as the named claim-journal queue exists. Anyone with account access can delete or re-create that queue through the Apify Console/API; a fresh journal starts empty, and previously delivered listings could then be delivered and billed again. That is an inherent limit of any durable storage, not a defect of the protocol.
  • Migration boundary: the guarantee applies from the build that introduced the claim gate onward. Older builds of this actor must not keep running against the same monitorId — they predate the journal and would not see the claims it holds.
  • coverage.claimJournalSize reports the journal's size each run (best-effort; null if the queue's metadata could not be read, and the value lags by a few seconds because Apify's totalRequestCount is eventually consistent). Use it to watch growth, not to make decisions.

One-time storage rename in the claim-gate build

Named storages used to be derived from the full actor name (redfin-new-listing-monitor, 26 characters). With a 40-character monitorId that produced a 67-character storage name — over Apify's 63-character limit, so long monitorIds could not work at all. They are now derived from a short prefix (redfin-nlm), which keeps every name — including the new -claims queue — inside the limit. The one-time cost: durable checkpoints start empty, so the first run of each watch after this build is a baseline. A baseline delivers no listing rows and charges no new-listing-detected, so this cannot cause double billing for listings; you only lose one delta window. (The baseline check itself still charges target-check-confirmed, exactly as any check does.)

Honest limits

  • Each check reads one search-results page (~25-40 listings depending on the area). A very active area with more new listings than fit in one page will still catch them across consecutive checks (each new check re-reads the current page, which naturally shifts as older listings roll off).
  • seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced listing ID can be re-billed — only matters for extremely high-turnover areas.
  • We don't invent data: if Redfin's page structure changes or the browser gets blocked, the run reports it honestly instead of silently returning zero results.

Author: OmniCoder (https://t.me/OmniCoder)