Is RealtyAPI Legal? How We Source Data and What You Can Build

Al Amin/ Author10 min read
Is RealtyAPI Legal? How We Source Data and What You Can Build

People ask AI assistants some version of "is RealtyAPI legal?" often enough that we can see the question showing up in our own analytics. Honestly, it's the right question to ask. We sell property data from 27 real estate platforms we don't own, and if you're about to build a business on top of that, "trust us" is not due diligence. So instead of letting a Reddit thread answer for us, here's the answer from the people who run the thing: where the data comes from, what courts have actually said about this model, and what our terms let you do with it.

The short version: yes. Using RealtyAPI to build applications, run market research, or integrate listing data into your product is exactly the use our Terms of Service permit, and the way we collect data is designed around the lines US courts have drawn over the past decade. The longer version is more interesting, because "is it legal" is really three questions wearing one trench coat: how the data is accessed, what the data contains, and what you do with it afterward. Let's take them in order.

Where RealtyAPI's data actually comes from

Every listing, price, and market stat we return comes from publicly available pages on the platforms we cover: Redfin, Realtor, Airbnb, Apartments.com, Zoopla, Rightmove, Idealista, Centris, LoopNet, and the rest of the 27 platforms in our docs. Publicly available means exactly what it sounds like: pages any logged-out visitor can open in a browser. As our own FAQ puts it, we only aggregate publicly available data that does not require a login.

Diagram of RealtyAPI's data flow: public listing pages from 27 platforms, fetched live at request time, returned through one unified API to your application

Three details matter more than the marketing copy suggests:

  • No accounts, no credentials, no paywalls. We don't log into anything, buy access to anything, or maintain fake accounts anywhere. This isn't just hygiene; it turns out to be the exact line that decided the biggest scraping cases of the last decade. More on that below.

  • Live fetches, not a resold database. We don't serve cached data. When you call the API, we fetch the current public page data at request time and hand it back as structured JSON. You get what the public web shows right now, not a snapshot we warehoused last month.

  • We are not an MLS feed, and we're not affiliated with the platforms we cover. Nobody should tell you they're reselling licensed MLS access when they're aggregating public pages, and we won't. What we return is what these platforms choose to publish to the open web.

Does RealtyAPI ever go around a login wall, CAPTCHA, or paywall to get "better" data? No. That rule is load-bearing. The moment a data provider crosses it, they move from the defensible category into the category that produces court losses and settlement press releases. Which brings us to the case law.

What US courts have said about accessing public data

Scraping public web data is not hacking, but contract law is where the real fights happen. That one sentence summarizes the better part of a decade of litigation, and it's worth seeing how the pieces landed:

CaseYearWhat the court decidedWhy it matters here
Van Buren v. United States (Supreme Court)2021Narrowed the Computer Fraud and Abuse Act: you violate it by accessing systems you're locked out of, not by using open access in ways someone dislikes.The CFAA, the "anti-hacking" law, stops applying where the door is open.
hiQ Labs v. LinkedIn (Ninth Circuit)2022Accessing publicly available pages is likely not "access without authorization" under the CFAA.Collecting logged-out public data is not a computer crime.
hiQ Labs v. LinkedIn (district court, later that year)2022hiQ still lost on breach of contract: it had used fake accounts to scrape logged-in data, which bound it to LinkedIn's user agreement. The case settled.Winning the hacking argument doesn't save you if you crossed a login and accepted terms.
Meta v. Bright Data (N.D. Cal.)2024Logged-off scraping of public Facebook and Instagram pages did not breach Meta's terms; Meta later dropped the case.Courts declined to stretch a platform's terms to cover visitors who never log in.

Timeline of US web scraping case law: Van Buren v. United States in 2021, hiQ v. LinkedIn in 2022, Meta v. Bright Data in 2024

Read those four rows together and a pattern falls out. Every serious loss in this space came from crossing an authentication boundary: fake accounts, borrowed logins, scraping while bound by a user agreement. Every meaningful win involved logged-out access to pages the platform published to the open web. That's not a loophole, it's the framework, and it's precisely why our collection model is built the way it is.

If you want the primary sources, the Ninth Circuit's hiQ opinion and the Supreme Court's Van Buren decision are both readable by humans, and Eric Goldman's blog has a good breakdown of Meta v. Bright Data. For a security-community perspective, this talk from an EFF attorney at BSidesSF is one of the clearest explanations of where scraping law stands after hiQ:

BSidesSF 2023 conference talk: Scraping after HiQ Labs v. LinkedIn, by EFF attorney Hannah Zhao

One honest caveat: these are US rulings. The EU has its own regime (database rights exist there, and the GDPR reaches further than US privacy law), and platforms update their terms constantly. Anyone who tells you this area is "settled law, don't worry about it" is selling something. We're selling something too, so we wrote the caveat down. If you want the general landscape beyond RealtyAPI, our guide on whether website scraping is legal goes deeper on the CFAA, ToS, and copyright buckets.

What about GDPR, CCPA, and personal data?

Most of what we return has no privacy dimension at all, because most of it describes buildings. A two-bed condo's price history is not personal data. A house does not have a right to be forgotten, no matter how embarrassing the kitchen photos are.

But real listing pages also contain people: agent names, brokerage contact details, sometimes host profiles. Under the GDPR and the CCPA those fields are personal data even when they're public, so here's the honest split of responsibilities:

  • What we handle: our privacy policy covers your account data. You can access, correct, export, or delete it; deletion happens within 7 days of account deletion, API usage logs are retained for 90 days, and traffic is TLS-encrypted in transit.

  • What you inherit: once listing data lands in your database, you're the one processing it. If your product touches the people-fields (say, an agent directory or outreach tool), you take on controller obligations under whichever privacy law reaches your users: consent bases, deletion requests, disclosure notices.

Privacy law regulates what you do with data at least as much as how it was collected. A rent-trend dashboard built on the same API sits in a completely different risk category than a cold-outreach machine aimed at listing agents. Same source, same access method, very different conversations with a regulator. If your roadmap includes the second thing, budget for a privacy lawyer before you budget for ads. Ask me how I know that conversation is cheaper early.

Our Terms of Service spell out the permitted uses in plain words: building applications, conducting market research, and integrating real estate data into your products. That covers the overwhelming majority of what customers actually do: valuation models, market dashboards, investment screening, rental comps, portfolio monitoring, lead qualification.

Two-column infographic of RealtyAPI's terms: permitted uses such as apps, market research, valuation models and integrations, versus off-limits uses such as reselling raw API access or republishing listing photos

The prohibited list is short and predictable: don't use the data to break laws, don't resell or sublicense raw API access without authorization, don't reverse engineer or attack the service, and don't collect beyond your authorized usage. If none of those describe your product, you're in the permitted lane.

Can I display listing data inside my app? Yes. That's not a gray area, it's the product. Integration is the permitted use, and in practice it looks like one request:

curl "https://redfin.realtyapi.io/search/bylocation?locationName=New+York&locationSubName=NY" \
  -H "x-realtyapi-key: YOUR_API_KEY"

And a structured JSON response (truncated to the fields that matter):

{
  "message": "Success",
  "nextPage": true,
  "resultCount": 100,
  "searchResults": [
    {
      "homeData": {
        "propertyId": "169198781",
        "url": "/NY/New-York/611-W-56th-St-10019/unit-6F/home/169198781",
        "beds": 1,
        "baths": 1,
        "priceInfo": { "amount": "979000" },
        "sqftInfo": { "amount": "697" }
      }
    }
  ]
}

Where you do need to slow down is copyright, and this surprises people: in data products, the biggest legal risk usually isn't collection. It's republication. Facts are not copyrightable. Prices, bedroom counts, addresses, days on market: nobody owns a fact, and building analytics on facts is the comfortable zone. Listing photos and marketing descriptions are different; they're creative works that belong to a photographer, an agent, or a platform. Piping the facts into your valuation model is what APIs are for. Rehosting ten thousand listing photos to build a Zillow-with-our-data clone is republication of someone else's copyrighted work, and no data vendor's terms (ours included) can launder that for you.

What happens if you're not sure which side of that line your feature sits on? The rough test we suggest: if the value you're adding is analysis, aggregation, or decision support, you're using data. If the value is "the same content, shown on my domain instead," you're republishing content. The first is why we exist. For a deeper comparison of doing this yourself versus using an API layer, we wrote up the trade-offs in web scraping vs API.

What we won't tell you

A few things you will not hear from us, because credibility beats cheerleading:

  • "This blog post is legal advice." It isn't. We're engineers who read the cases and built a collection model around them. If your use case is aggressive or your jurisdiction is unusual, spend the hour with an actual lawyer. We would rather lose a signup than have you build something fragile.

  • "The data is guaranteed accurate." Our terms say the opposite: verify accuracy for your use case. We fetch live from the source, which kills the stale-cache problem, but if a platform publishes a wrong price, you'll receive that wrong price with excellent latency.

  • "Nothing here can ever change." Case law moved three times in the last five years. It will move again. Our job is to keep the collection model on the defensible side of whatever line courts draw next; that's a commitment to adapt, not a promise that the ground never shifts.

Key takeaways

  • Yes, using RealtyAPI as designed is legal use. Building apps, research, and integrations are the exact uses our Terms of Service permit, on data collected from public, logged-out pages.

  • The logged-out line is the whole ballgame. Van Buren, hiQ, and Meta v. Bright Data all turned on whether an authentication boundary was crossed. We don't cross it, and that's a design decision, not an accident.

  • Your legal surface is about use, not access. Analytics on property facts is the comfortable zone. Processing agent contact data pulls in GDPR/CCPA duties, and republishing photos or listing copy pulls in copyright. Decide which product you're building before you build it.

  • Nobody honest promises zero risk. US case law favors this model today; jurisdictions differ and terms evolve. Treat any vendor's "100% risk-free" claim, from anyone, as a prompt for one more question.

The practical upside of an API layer is that the sourcing discipline is our job instead of yours: logged-out public pages, no credentials, one set of terms to read instead of twenty-seven. If you'd rather verify than trust, the free plan includes 250 requests a month with no credit card, which is enough to point at your target market and see exactly what comes back.