# Redfin New Listing Monitor (`titan_coder/redfin-new-listing-monitor`) Actor

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.

- **URL**: https://apify.com/titan\_coder/redfin-new-listing-monitor.md
- **Developed by:** [Radu Furtuna](https://apify.com/titan_coder) (community)
- **Categories:** Real estate, Lead generation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

Pay per event

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Redfin New Listing Monitor

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

```json
{
  "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 item | per 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 `monitorId`s 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)

# Actor input Schema

## `monitorId` (type: `string`):

Name of this monitor's durable history (a-z, 0-9, dash; up to 40 chars).

## `cdpUrl` (type: `string`):

Optional. Leave EMPTY to use the built-in stealth anti-detect browser — no third-party account or key needed. Provide your own Bright Data Scraping Browser endpoint (wss://<user>:<pass>@brd.superproxy.io:9222) only if you prefer to route through your own browser. The backend is never switched automatically: whatever you set here is what is used, and it is reported in the run's coverage.

## `watches` (type: `array`):

1-15 objects: {"watchId": "austin-tx", "searchUrl": "https://www.redfin.com/city/30749/TX/Austin"}. searchUrl must be a Redfin city/zipcode/county/neighborhood search page. New watches can be added later under the same monitorId.

## `notifyOn` (type: `string`):

new\_alerts — post the webhook only when new paid listings were delivered; always — post it every run; never — do not call webhookUrl at all.

## `webhookUrl` (type: `string`):

Optional. Receives a digest of delivered (paid) new listings as JSON. HTTPS only.

## Actor input object example

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

# Actor output Schema

## `results` (type: `string`):

Every row this run produced. Key fields: watchId, listingId, address, price, currency, discoveredAt.

## `coverage` (type: `string`):

What this run actually covered and what it charged for: per-target status and reason, rows delivered and rows billed. Enough to reconcile every charge against every row.

## `digest` (type: `string`):

A short human-readable summary of what this run found, written every run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "monitorId": "my-search",
    "watches": [
        {
            "watchId": "austin-tx",
            "searchUrl": "https://www.redfin.com/city/30818/TX/Austin"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("titan_coder/redfin-new-listing-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "monitorId": "my-search",
    "watches": [{
            "watchId": "austin-tx",
            "searchUrl": "https://www.redfin.com/city/30818/TX/Austin",
        }],
}

# Run the Actor and wait for it to finish
run = client.actor("titan_coder/redfin-new-listing-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "monitorId": "my-search",
  "watches": [
    {
      "watchId": "austin-tx",
      "searchUrl": "https://www.redfin.com/city/30818/TX/Austin"
    }
  ]
}' |
apify call titan_coder/redfin-new-listing-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,titan_coder/redfin-new-listing-monitor"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/4ESuINRX77MpX8weu/builds/fBQL9JoNRiANE8bZg/openapi.json