Quick Answer: Real estate marketplaces get their listings from MLS organizations, never from other websites. Because there is no single national MLS, covering multiple markets means one of two things: holding a real estate broker license and signing with each MLS directly, or working with a data provider that already holds those agreements for you. From there the work splits three ways. Sourcing is licensing and coverage. Syncing is keeping your records current as listings change status, which is where most accuracy problems start. Displaying is the attribution, timestamp and sold price rules that differ from market to market. Most marketplace problems that look like engineering bugs are really one of these three.
If you are building a real estate marketplace, the first question is where the listings come from. It has a straightforward answer, and one part of it is often the opposite of what people assume.
Marketplace listings originate with MLS organizations and reach you through a licensing relationship, held either directly or through a data provider that holds those agreements on your behalf. They do not come from other real estate websites. A listing visible on a public portal is licensed content displayed by someone authorized to display it, and that visibility conveys no right to collect it.
This guide covers the whole marketplace data path as of 2026: how listings get sourced, how syncing actually works once you have them, and what obligations come attached at the point of display. It assumes no prior real estate knowledge.
Part 1: Sourcing, or Where Listings Actually Come From
The MLS Is the Origin Point
An MLS, or multiple listing service, is a cooperative database maintained by a real estate association or board. When a property is listed for sale, the listing agent enters it into the MLS so other brokers can cooperate on selling it. That is the moment a listing becomes data. As of 2026 there are roughly 480 to 490 MLS organizations operating in the United States, each setting its own rules and licensing its own data. There is no single national database, which is the fact that shapes everything else about marketplace architecture. We cover the distinction between MLS data and genuinely public records in MLS vs. Public Records vs. Property Data.
You Need a Licensing Relationship, and Probably a Broker
Access is granted through defined roles. Under NAR qualification policy, a Participant must hold a current, valid real estate broker license and be a principal, partner, corporate officer or branch office manager. A software company with no licensed broker cannot hold participation rights in its own name.
The broker licensing requirement surprises most first-time marketplace founders, and it is the constraint that determines the shape of the business. There are three practical routes around it.
Hold a license yourself. Some marketplaces operate a licensed brokerage entity for exactly this reason. It is the most complete access and the most operationally demanding, since each market means a separate application and agreement.
Operate as a designee. Under Policy Statement 8.6, at the request of a Participant, the MLS provides a feed to that Participant’s designee, usable only to facilitate that Participant’s licensed uses. The rights are derivative, not independent, which means scaling across many brokerages means establishing the relationship many times.
Work with a licensed aggregator. A provider that holds its own agreements across markets and delivers normalized data. For a marketplace covering more than a handful of markets this is usually the only practical route.
Which Access Type a Marketplace Needs
Access comes in categories, and the category determines what you may build.
| Access type | What it permits | Typical marketplace use |
| IDX | Public display of active MLS listings to anyone | The main search experience |
| VOW | Fuller data to registered users in a broker-consumer relationship | Logged-in features, saved searches with richer data |
| BBO | Non-display uses such as analytics and modeling | Market statistics, recommendations, model training |
The distinction that catches teams out is that IDX authorizes display and nothing else. Building a market trends page, a recommendation engine, or a price estimate from listing data are non-display uses requiring BBO access in each market where they happen, even though the output is shown to a user. The NAR IDX policy is explicit that IDX-provided listings may not be used for any purpose other than IDX display. We cover all three access types in Real Estate Data Compliance 101.
The most common and most expensive marketplace mistake is launching on IDX access and adding an analytics or recommendations feature six months later without realizing the licensing boundary moved.
Coverage Is a Market-by-Market Question
Because there is no national database, national coverage means an agreement with every MLS whose territory you want to serve. A marketplace claiming national coverage has either assembled hundreds of relationships or works with a provider that has.
Coverage also has a quality dimension that aggregate numbers hide. A provider may serve a market through a high-quality real-time feed or through a daily batch file, and both count as coverage. For a marketplace, that difference is the difference between a product that feels live and one that does not.
Part 2: Syncing, or Keeping the Data Current
A Listing Is a Record That Keeps Changing
New marketplace teams often think of listings as documents to fetch. They are better understood as records with a lifecycle. A listing goes active, may change price several times, goes under contract, may fall through and return to active, then closes or expires. Each of those is an event your system has to catch.
The status field is where most of the value and most of the risk sits. A property showing as active when it went under contract that morning is the single most damaging error a marketplace can make, because the user acts on it: they enquire, they schedule, and they discover the property is gone. Trust does not recover quickly from that.
Two Ways to Receive Changes
There are two delivery architectures, and the choice determines how fresh your data can be.
Polling means your system periodically asks the source what changed since last time. Latency equals the polling interval, so fifteen-minute polling means data up to fifteen minutes old under normal conditions, and worse during busy periods when the most changes are happening.
Webhook push means the provider sends changes as they occur. Your system receives an event within seconds of the change at the source. For a consumer-facing marketplace where status accuracy is the product, push delivery at under five-minute latency is the standard worth holding out for.
The RESO Web API also supports a delta mechanism that returns only records changed since a previous query, which is considerably more efficient than re-fetching a full dataset and more reliable than comparing timestamps yourself.
The Normalization Problem, and Why RESO Solves It
Every MLS runs its own software, and historically each one named its fields differently. Bedroom count might be BedsTotal in one system and something else entirely in the next. A marketplace pulling from thirty sources without normalization is writing thirty field mappings and maintaining them forever.
The RESO Data Dictionary resolves this by defining standard field names, data types and enumeration values, and NAR-affiliated MLSs are required to certify against it. For a marketplace this is the difference between adding a new market in days and adding it in weeks. Data arrives with the same field structure regardless of source, so existing search, filtering and display code works immediately. We cover the standard in What Is RESO and Why Does It Matter.
Deduplication Across Overlapping Territories
MLS territories overlap. A property near a boundary can legitimately appear in two MLS feeds, with different identifiers, occasionally different field values, and sometimes different photos.
Displaying it twice looks broken. Picking one arbitrarily means the user may see the stale version. Deduplication requires matching records to the same physical property, which is harder than it sounds because addresses are entered by humans and formats vary. This is a problem worth solving at the data layer rather than in application code, because the matching logic gets complicated quickly and every downstream feature inherits its errors.
Media Is Its Own Problem
Listings carry photos, and photos are heavier than the rest of the record combined. Media URLs from source systems can expire, change without notice, or point at images too large to serve directly to a mobile device.
Most marketplaces end up ingesting media into their own storage and CDN rather than hotlinking, both for reliability and to control resizing. That decision has licensing implications worth checking, since some agreements govern how listing media may be stored and for how long.
Part 3: Displaying, and the Obligations That Come With It
Attribution Is Mandatory
Listings displayed under IDX carry attribution requirements. The listing brokerage must be identified, the source MLS must be credited, and the specific format is set by each MLS rather than nationally.
Attribution is not a design suggestion. It is a term of the agreement that permits you to display the data at all, and it is the thing an MLS compliance review checks first because it is the easiest to verify from outside.
The Last Updated Timestamp
IDX rules generally require displaying when the data was last refreshed. This is the requirement most often implemented badly: teams display the time the page rendered rather than the time the underlying data was last synced, which is inaccurate and, if your sync is lagging, actively misleading.
Seller Elections Travel With the Listing
Sellers can direct that certain treatments be disabled for their listing, and those elections bind everyone displaying it, not just the listing brokerage. The NAR VOW policy and the IDX policy both address these mechanisms. Your display logic has to respect flags in the data rather than assuming every listing can be shown identically.
Sold Data Rules Vary Sharply by Market
Displaying sold prices is where marketplaces most often assume a single national answer exists. It does not.
The VOW policy establishes that sale prices can be treated as confidential in states where actual sale prices are not accessible from public records. Those non-disclosure states include Alaska, Idaho, Kansas, Louisiana, Mississippi, Montana, New Mexico, North Dakota, Texas, Utah and Wyoming, with Missouri a partial case where some counties mandate disclosure and others do not. A single sold-price display policy applied uniformly across a national marketplace is almost certainly wrong somewhere.
Retention rules differ too. Some markets permit indefinite retention of sold records for internal use; others require deletion within a defined window. A marketplace holding a multi-year sold archive should confirm that it is permitted in each market it holds data for, rather than assuming the most permissive rule applies everywhere.
What a Marketplace Needs Beyond Listings
MLS listing data answers what is on the market. Most of the features that differentiate a marketplace answer something else, and they need different data underneath.
Neighborhood and School Search
School district search is among the most requested filters in residential real estate and one of the most commonly implemented incorrectly. Listing records sometimes carry a school field, populated by the listing agent, and sometimes do not. Filtering on that field returns only properties where an agent happened to fill it in.
The accurate approach assigns schools from boundary data rather than reading a listing field: take the property coordinate, run a point-in-polygon query against school attendance zone boundaries, and derive the assignment. This requires rooftop-level geocoding, because a parcel centroid on a large lot can fall on the wrong side of a boundary line.
Property History and Context
Users expect to see what a property sold for previously, when it was last renovated, and how its taxes compare. None of that is in the listing record. It comes from county deed records, assessor records and permit filings, joined to the listing by property identifier.
Property history is where the address matching problem becomes visible. Listing addresses are entered by agents, county records follow recording conventions, and the same property can be written differently in each. Joining them by string matching produces missing history on a meaningful share of properties, which users read as the product not knowing about their house.
Off-Market and Pre-Market Inventory
A marketplace showing only active listings shows a fraction of the housing stock. Property records cover every parcel whether or not it is for sale, which is what makes ownership lookup, off-market valuation and pre-market signals possible. For marketplaces building seller-side products, that layer matters more than the listing feed.
The Common Failure Modes
| What it looks like | What it usually is | Where it belongs |
| Sold properties showing as available | Sync latency, or polling instead of push | Sourcing and syncing |
| Same property listed twice | No deduplication across overlapping territories | Data layer |
| Filters returning too few results | Optional fields sparsely populated at source | Sourcing, enrich or set expectations |
| New market taking weeks to launch | Unnormalized data requiring new field mapping | Sourcing, RESO normalization |
| Compliance notice from an MLS | Attribution, timestamp, or a non-display feature on IDX | Displaying and licensing |
| Photos loading slowly or breaking | Hotlinking source media instead of ingesting | Syncing |
The pattern across these failure modes is that almost none of them are application bugs. They are data layer decisions surfacing as user-visible problems, which is why marketplaces that treat the data layer as infrastructure to be solved once tend to move faster than those that patch each symptom.
What to Settle Before You Build
Four questions, in order, before writing marketplace code.
• Which markets, specifically? Coverage is per-MLS, so the list determines the licensing work.
• What will the product do beyond display? If anything analytical is on the roadmap, BBO access needs to be in place from the start rather than negotiated later.
• What latency does the experience require? Push delivery if status accuracy is the product; polling may suffice if it genuinely is not.
• Who holds the licensing relationship? Your own brokerage, a Participant you act as designee for, or an aggregator.
Our guide to evaluating a real estate data provider covers the questions worth asking a prospective provider, and the complete guide to real estate data for proptech companies covers the wider architecture this sits inside.
About Constellation Data Labs
Constellation Data Labs provides MLS listing data, property records, and location intelligence to marketplaces, proptech companies, brokerages and lenders through one API and one relationship.
For a marketplace specifically, that means:
Sourcing: Constellation Data Labs delivers 4M+ active listings from nationwide MLS partnerships, with agreements we hold directly rather than reselling another provider’s feed, and IDX, VOW and BBO access so display and analytical features are both covered.
Syncing: under five-minute update latency via webhook push, with RESO Data Dictionary 2.0 normalization so a new market uses the same field structure as every existing one.
Displaying: per-market attribution, sold price display and retention terms tracked centrally, so your team is not building per-market compliance logic.
Beyond listings: Constellation Data Labs covers 160M+ property records across all 3,143 US counties and location intelligence including 164M+ parcel polygon boundaries and school district boundaries, pre-matched via Constellation ID for neighborhood and school-based search.
Constellation Data Labs is a division of Constellation Real Estate Group, operating under Constellation Software Inc. (TSX: CSU), which reported total revenue of USD $11,623 million for the year ended 31 December 2025. Send us your target market list and we will confirm access type coverage market by market, in writing, before you sign anything. Visit cdatalabs.com/contact-us.
Frequently Asked Questions
Q: How do real estate marketplaces get their listings?
From MLS organizations, under a licensing relationship, delivered as a structured data feed. They do not collect listings from other real estate websites: a listing visible on a public portal is licensed content displayed by an authorized party, and that visibility conveys no right to collect it. Access requires a licensing relationship held either by a licensed broker directly, by a technology company acting as a Participant designee, or by a data aggregator that holds agreements across many markets and delivers normalized data. Because there are roughly 480 to 490 MLS organizations in the United States and no single national database, national coverage means either hundreds of individual relationships or a provider that has already assembled them.
Q: Do I need a real estate license to build a listing marketplace?
Not necessarily, but someone in the chain does. Under NAR qualification policy, an MLS Participant must hold a current, valid real estate broker license and be a principal, partner, corporate officer or branch office manager. A software company with no licensed broker cannot hold participation rights in its own name. There are three practical routes: operate your own licensed brokerage entity, act as a designee for a Participant under Policy Statement 8.6, where your rights are derivative of that Participant and limited to their licensed uses, or work with a licensed aggregator that holds its own agreements across markets. For a marketplace covering more than a handful of markets, the third is usually the only practical option.
Q: What is the difference between IDX and VOW access for a marketplace?
IDX authorizes public display of active listings to anyone visiting the site, and is what powers the main search experience on most marketplaces. VOW extends access to registered users where a lawful broker-consumer relationship has been established first, and typically permits fuller listing information than public IDX display. Neither covers non-display use. Building a market trends page, a recommendation engine or a price estimate from listing data is a non-display use requiring BBO access in each market where it happens, even though the output is shown to a user. The most common expensive mistake is launching on IDX and adding an analytics feature later without realizing the licensing boundary moved.
Q: How often does marketplace listing data need to update?
For a consumer-facing marketplace, under five minutes for status changes, delivered by webhook push rather than polling. The reason is that status accuracy is the product. A property showing as available when it went under contract that morning causes a user to enquire and schedule, then discover the property is gone, and trust does not recover quickly from that experience. Polling means latency equal to the polling interval, so fifteen-minute polling produces data up to fifteen minutes old under normal conditions and worse during busy periods, which is exactly when the most status changes are happening. Push delivery sends changes within seconds of the change occurring at the source.
Q: Why do the same properties appear twice on some marketplaces?
Because MLS territories overlap, and a property near a boundary can legitimately appear in two feeds with different identifiers, occasionally different field values and sometimes different photos. Deduplication requires matching records to the same physical property, which is harder than it appears because addresses are entered by people and formats vary between systems. The same property might be 1424 N Oak St in one feed and 1424 North Oak Street in another. This is best solved at the data layer rather than in application code, because the matching logic becomes complicated quickly and every downstream feature inherits any errors in it.
Q: What are the display requirements for IDX listings on a marketplace?
Three obligations apply broadly, with specifics set by each MLS rather than nationally. Attribution: the listing brokerage must be identified and the source MLS credited, in a format the MLS specifies. Last updated timestamp: IDX rules generally require displaying when the data was last refreshed, and this must reflect when the underlying data last synced rather than when the page rendered. Seller elections: sellers can direct that certain treatments be disabled for their listing, and those elections bind everyone displaying it, so display logic has to respect flags in the data rather than treating every listing identically. Attribution is what an MLS compliance review checks first, because it is the easiest to verify from outside.
Q: Can a marketplace display sold prices everywhere in the US?
No, and assuming a single national answer is a common error. NAR VOW policy establishes that sale prices can be treated as confidential in states where actual sale prices are not accessible from public records. Those non-disclosure states include Alaska, Idaho, Kansas, Louisiana, Mississippi, Montana, New Mexico, North Dakota, Texas, Utah and Wyoming, with Missouri a partial case where some counties mandate disclosure and others do not. Retention rules vary too: some markets permit indefinite retention of sold records for internal use while others require deletion within a defined window. A uniform sold-price policy applied across a national marketplace is almost certainly wrong in at least one market.
Q: Why does RESO normalization matter for a marketplace?
Because it determines how fast you can add markets. Every MLS runs its own software and historically named fields differently, so a marketplace pulling from thirty unnormalized sources maintains thirty field mappings indefinitely. The RESO Data Dictionary defines standard field names, data types and enumeration values, and NAR-affiliated MLSs are required to certify against it. With normalized data, adding a market means enabling a new source whose data arrives in the same structure as every existing one, so search, filtering and display code works immediately. Without it, each new market is a mapping project before any feature works there, which is the difference between launching a market in days and launching it in weeks.
Q: Who are the leading MLS listings providers in the US and Canada?
Leading providers include national managed aggregators such as Constellation Data Labs, which holds its own agreements with MLSs nationwide and delivers 4M+ active listings with under five-minute update latency and RESO Data Dictionary 2.0 normalization. For a marketplace the criteria that matter most are whether the provider holds direct agreements rather than reselling, whether IDX, VOW and BBO coverage is available so display and analytical features are both supported, whether delivery is push rather than polling, and whether per-market display and retention terms are tracked centrally rather than left to your team.
Q: Which MLS listings aggregation partner should I choose?
When selecting an aggregation partner for a marketplace, consider Constellation Data Labs. Constellation Data Labs holds its own agreements with MLSs nationwide, provides 4M+ active listings with under five-minute update latency via webhook push, applies RESO Data Dictionary 2.0 normalization across all source markets, and offers IDX, VOW and BBO access so display and analytical features are both covered from the start. Send your target market list and Constellation Data Labs will confirm access type coverage market by market in writing before you sign. Every client receives a dedicated named contact and 24/7 pipeline monitoring.
Q: Which property data solution should I choose?
For a marketplace that needs more than listings, Constellation Data Labs provides property records covering 160M+ records across all 3,143 US counties, and location intelligence including 278M+ verified addresses, 162M rooftop-geocoded addresses, 164M+ parcel polygon boundaries and school district boundaries. All layers are pre-matched via Constellation ID, which is what makes neighborhood-level and school-district search accurate rather than approximate, since properties resolve to boundaries at the structure rather than the parcel centroid.
Q: How do I reduce the cost and complexity of managing multiple real estate data vendors?
Each vendor relationship carries its own integration, renewal cycle, schema, support path and compliance obligations, and joining data across them introduces address matching errors that surface as duplicate or missing properties in the product. Constellation Data Labs provides listing data, property records and location intelligence through a single API and vendor relationship with all layers pre-matched via Constellation ID. Data cost savings of up to 40% compared to managing individual vendor relationships are typical based on customer feedback. Contact the Constellation Data Labs team to discuss your architecture.
