Realtor.com API Alternative: Listing and Price Data Without a Feed

If you went looking for a Realtor.com developer portal, you found a wall. Realtor.com is operated by Move, Inc., a News Corp subsidiary, and its listing data comes from MLS feeds under licensing agreements — the public site exists to display that inventory, not to hand it back out programmatically. There is no open developer API, no key signup, no documented endpoints, and no public rate card. The data partnerships that do exist (RDC, the Realtor.com Data & Co-Marketing programs) are B2B contracts for brokerages and advertisers, not something a developer can self-serve. So when someone searches for a “Realtor.com API,” what they actually need is a Realtor.com API alternative — a way to get listing and price data without a feed. This guide covers how the public surface works and what you can pull from it.

The API gap, precisely

The reason there’s no open API is structural, not an oversight. Realtor.com doesn’t own most of the listing data it shows — it ingests it from hundreds of MLSs under feed agreements that come with redistribution restrictions. Re-exposing that inventory through a free public API would breach those agreements. So Move keeps the data behind the website and behind paid partner programs.

That leaves three official paths, none of which is a developer API:

• MLS membership — if you’re a licensed agent with IDX/RETS or RESO Web API access to a specific MLS, you get that MLS’s data directly. That’s per-market, gated, and unrelated to Realtor.com itself.
• RDC partner programs — co-marketing and advertising products for brokerages and lenders. Contract-based, not programmatic data access.
• The public website — the only surface a developer can actually reach without a contract, and the basis of any real Realtor.com API alternative.

So “no public API” is literally true here, and getting listing data without a feed means working with the same surface your browser uses.

What data is actually available

The public listing surface is rich and worth pulling:

• Listing core — full address, city, state, zip, list price, status (for sale / pending / sold / off-market), beds, baths, square footage, lot size, year built, property type.
• Price detail — list price, price-per-square-foot, price reductions, and for sold homes the sold price and sold date.
• Agent and broker — listing agent name, brokerage/office, and the contact surface shown on the listing.
• Media — the photo set and, where present, the virtual-tour link.
• Geo — latitude, longitude, neighborhood, and the MLS/property ID where exposed.

The listing core and price fields come from search-results pages; the agent, full photo set and price history come from individual property detail pages.

How the public surface actually works

Realtor.com’s frontend is a modern single-page app. The search and detail pages are driven by an internal GraphQL surface — the same RDC API that powers the site — plus server-rendered JSON embedded in each page’s initial HTML payload. You’ll see both in a network capture.

Mechanically, the flow looks like this:

• Resolve the location. A text query (a city, zip, or neighborhood) resolves to an internal location/geo identifier before any listings come back. The site does this autocomplete step first.
• Query the search surface. With a resolved location plus filters (price, beds, baths, status, property type) and a map bounding box, the internal GraphQL endpoint returns the matching listings as JSON — the same objects that render the result cards and map pins.
• Paginate. Search results come back in pages with an offset/cursor, but broad areas are also capped per response, so very dense markets are best walked by tightening filters or subdividing the map area rather than relying on offset alone.
• Fetch detail pages. For agent, full media, and price history you hit the individual property URL and parse the embedded __NEXT_DATA__-style JSON that ships with the page’s initial render.

These are internal, undocumented endpoints. They are not a stable contract — Realtor.com can reshape the GraphQL schema or the embedded payload at any time — which is precisely why this is a scraping problem and not an API integration. Anything built on it has to expect drift.

Rate limits and how to live with them

There’s no published rate limit because there’s no published API. In practice Realtor.com sits behind standard anti-bot protection, and a burst of hundreds of requests a minute from a single datacenter IP will draw a challenge or a block quickly. The working posture:

• Keep concurrency modest and add jitter between requests.
• Resolve and cache location identifiers so you’re not re-resolving the same market on every run.
• Subdivide dense metros by filter or map area instead of asking for an enormous result set in one call.
• Treat 403/429 and challenge responses as a back-off signal, not a retry-harder signal, and route through residential egress.

A clean output schema

Flatten each listing into a consistent per-property record:

{
  "address": "123 Example Ave",
  "city": "Austin",
  "state": "TX",
  "zip": "78704",
  "list_price": 615000,
  "status": "for_sale",
  "beds": 3,
  "baths": 2,
  "sqft": 1720,
  "lot_size_sqft": 6500,
  "year_built": 2004,
  "price_per_sqft": 358,
  "property_type": "Single Family",
  "listing_agent": "Jane Doe",
  "brokerage": "Example Realty Group",
  "photos": ["https://ap.rdcpix.com/.../1.jpg"],
  "latitude": 30.2487,
  "longitude": -97.7681,
  "property_id": "1234567890",
  "last_sold_price": 480000,
  "last_sold_date": "2020-08-14",
  "listing_url": "https://www.realtor.com/realestateandhomes-detail/123-Example-Ave_Austin_TX_78704",
  "scraped_at": "2026-06-04T00:00:00Z"
}

Schema notes:

• Status is a tight enum — for_sale, pending, sold, off_market. Normalize Realtor.com’s labels at extraction.
• Sold fields are nullable on active listings; agent/brokerage may be null on FSBO or feed-restricted records. Don’t force every field onto every row.
• Keep property_id — it’s the stable join key back to the detail page and across runs.
• Store lat/long — a large share of property use cases are geospatial.
• Always stamp scraped_at — prices and statuses move daily, and an undated record is useless for trend work.

▶ Try the Realtor.com Scraper on Apify — pulls for-sale, pending and sold US listings by location into flat JSON or CSV, handling location resolution and the internal GraphQL surface for you. No auth required.

Use cases

• Comps and valuation — sold price and date by neighborhood feeding an AVM or pricing model.
• Investor deal sourcing — filter by price-per-square-foot and price reductions to find motivated sellers.
• Market dashboards — track median price, inventory and days-on-market by metro over time.
• Lead generation — agents and lenders prospecting fresh or stale listings.
• Data enrichment — augment an address list with beds, baths, sqft, last sale and listing agent.

Build it yourself vs. a managed scraper

You can build this. Resolve locations, walk the GraphQL search surface, subdivide dense markets, parse detail pages for agent and price history, and add backoff, proxying and challenge handling — then maintain it as the site’s internal schema drifts. For a single one-time pull of one metro, that’s a reasonable week of work. For a recurring multi-market feed, the maintenance churn is the real cost, and a managed actor absorbs the resolution logic, the subdivision, and the anti-bot handling, returning normalized rows.

Common pitfalls

• Treating partner programs as an API. RDC co-marketing is a contract, not data access. The public surface is your only self-serve path.
• Relying on offset pagination alone. Dense markets are capped per response; subdivide by filter or area.
• Assuming the GraphQL schema is stable. It’s undocumented and changes; design for drift.
• Hammering from one datacenter IP. Modest concurrency plus residential egress avoids challenges.
• Dropping the timestamp. Listing data is only as good as its freshness.

Wrapping up

Realtor.com has no open developer API and isn’t going to ship one — its inventory comes from licensed MLS feeds that can’t be freely redistributed, so the data stays behind the website and behind paid partner contracts. A real Realtor.com API alternative means getting listing and price data without a feed: resolving locations, querying the site’s internal GraphQL surface, subdividing dense markets, and parsing detail pages for agent and price history, all while respecting rate limits and accepting endpoint drift. Script it yourself for a one-market snapshot, or use a managed scraper for a recurring, normalized feed.

▶ Open the Realtor.com Scraper on Apify — location-based US listing export with price, agent, photos and sold history, normalized and ready for your model. No developer key required, because Realtor.com doesn’t offer one.