MLS Data Access for Real Estate Platforms

The MLS is a broker cooperative. That distinction matters more than most platform builders initially appreciate. It is not a public utility, not a commercial data vendor, and not a government registry. It exists because brokers agreed to share their listings with each other in exchange for reciprocal access to everyone else's inventory. Think of it like a potluck dinner: you only get to eat if you brought something to the table. The access rules flow from that cooperative logic, not from any centralized authority, and understanding that changes how you think about every integration decision downstream.

Each MLS is independently governed, typically by a local or regional real estate association with its own membership structure, board, and bylaws. Access is restricted to licensed real estate professionals: agents, brokers, and those operating under broker sponsorship. The gatekeeping is not purely competitive posturing. MLS systems contain seller contact information, showing schedules, pricing history, and days-on-market data that is legitimately sensitive. The accountability structure of professional licensing is part of how that sensitivity gets managed, and that logic is here to stay.

Scale varies dramatically across the more than 500 systems operating in the U.S. California Regional MLS has more than 100,000 subscribers, making it the largest in the country. Northwest MLS covers much of Washington state and part of Oregon with more than 30,000 subscribers. At the other end, many MLSs serve a few hundred members in a single county. The governance structure and technical sophistication of each system reflects that range, which is why integrating in Los Angeles and integrating in rural Montana are genuinely different problems.

For a proptech company without a brokerage license, there are three viable entry points: broker sponsorship, a formal data licensing agreement negotiated directly with the MLS, or working through an aggregator that has already secured those agreements. Each path carries different costs, timelines, and compliance obligations, and picking the wrong one early is the kind of mistake that surfaces during a product launch rather than during architecture.

Data access tiers are frequently conflated, and conflating them is an expensive mistake. IDX governs consumer-facing display of active listings, with tight rules on refresh rates, attribution, and presentation. VOW covers registered-user access in a transaction context and carries its own additional requirements. Broker back-office licensing is a separate category covering analytics, data pipelines, and non-display applications. A platform building valuation infrastructure needs the third tier, not the first. Assuming otherwise can result in a feed agreement that technically exists but legally does not permit the intended use.

Geographic consolidation is happening. Smaller MLSs are merging into regional systems at a gradual pace. That consolidation has not meaningfully reduced the compliance burden for platforms needing coverage across multiple markets. The number of required bilateral relationships is declining slowly; the per-relationship complexity is unchanged.

The technical standards that underpin MLS data delivery today

RETS, the Real Estate Transaction Standard, was the dominant XML-based protocol for roughly two decades. RESO officially deprecated it in 2018, and several major vendors shut off RETS integrations in late 2024. If a platform is still running on RETS infrastructure, that is an active risk. A present one, not a deferred one.

The RESO Web API is the current standard: a REST and JSON architecture built on OData v4. Any developer comfortable with modern APIs can orient to the structure quickly. The field-level standard governing what data looks like inside that transport layer is the RESO Data Dictionary, with version 2.0 ratified in April 2024.

Adoption is substantially complete but not universal. As of 2025, 93% of U.S. MLSs are certified on RESO standards, and more than 75% have adopted the RESO Web API transport protocol. The National Association of Realtors requires all affiliated MLS organizations to adopt new RESO standard releases within one year of ratification, which is the mandate that produced those numbers. The remaining 7% are disproportionately smaller, more regional systems serving secondary and rural markets: precisely the markets that are hardest to cover and last to standardize.

One thing worth making explicit because it trips up developers consistently: you do not contact RESO directly to get credentials. The actual sequence is to obtain IDX or VOW approval from the MLS first; the MLS then directs you to its technology vendor, commonly CoreLogic's Trestle platform, MLS Grid, Bridge Interactive, Spark by FBS, or Paragon; the vendor issues the API endpoint and OAuth2 credentials. The vendor is the authentication and access layer. The standard defines what the data looks like once you are inside. These are separate concerns. Confusing them adds weeks to integrations that should take far less time.

Why shared standards have not solved the data normalization problem

The RESO Data Dictionary defines roughly 1,300 standardized fields. Per analysis from WAV Group in 2024, those fields represent approximately 70% of the data actually stored in a typical MLS. The remaining 30% is local and market-specific, outside the scope of what the standard captures.

That 30% is not noise. It is often the most differentiated data in a regional market. Waterfront access classifications. Ski-in/ski-out designations. Hurricane shutter presence. Agricultural land fields. Flood zone specifics. These are the fields that make a listing meaningfully distinct from another listing in the same zip code, and they are frequently the fields that a VOW application or an analytics platform most needs to be useful in that market.

This creates a two-layer normalization problem. The first layer is standardizing the fields RESO covers across the 500-plus MLSs that have certified against it. That layer is substantially solved for the 93% that are certified. The second layer is mapping or ingesting the local, non-standard fields that RESO does not define. That layer requires MLS-specific work regardless of which aggregator a platform uses, because no aggregator standardizes what the standard itself does not reach.

Platform builders who discover this gap after integration generally rediscover it as a product problem: the data model built against a normalized feed does not have the fields the analytics features require in specific markets. The correct time to plan for it is during architecture. Finding it during QA means rebuilding something you already built.

The four main paths to getting MLS data and what each one actually requires

Direct MLS integration

Direct integration means negotiating independently with each MLS, obtaining IDX or VOW approval, and then working with that MLS's technology vendor for credentials and endpoint configuration. Approval timelines vary considerably: days in some markets, months in others, depending on the MLS's staff capacity and governance processes. Direct data license fees generally run in the range of tens to hundreds of dollars per month per MLS, plus setup costs.

This path makes sense for platforms with narrow geographic focus or for those that require full field access, including non-standard local fields, in specific high-priority markets. It is not viable as a sole strategy for national coverage. Managing hundreds of bilateral relationships, each with its own renewal cycles, compliance reviews, and technical configurations, is operationally prohibitive at scale.

MLS data aggregators

Aggregators have pre-negotiated agreements with multiple MLSs and expose them through a single normalized API. This is the dominant approach for platforms requiring multi-market coverage, and for good reason.

CoreLogic Trestle aggregates data from more than 300 MLSs through a single RESO-compliant API. It handles board approvals, field-level restrictions, and feed maintenance. Platforms depending on active listing data, status changes, and media at scale consistently use Trestle as a primary aggregation layer.

MLS Grid works with more than 2,200 brokerages and technology companies across 34 MLS markets, representing approximately 360,000 MLS subscribers. It was founded by a coalition of MLSs specifically to preserve local governance while simplifying vendor access, which makes its model structurally different from purely commercial aggregators. That origin matters for how it negotiates and how it evolves.

Bridge Interactive, now part of Zillow Group, focuses on helping MLSs distribute listing data across platforms via a single RESO-compliant feed, with pricing starting around $500 per month for MLS-wide feeds. Spark by FBS offers developer-facing access to listings, saved searches, and market statistics; access requires MLS membership or broker sponsorship, which makes it more appropriate for platforms already operating within that professional credentialing structure.

One clarification that matters and gets glossed over constantly: aggregators do not eliminate compliance obligations. They absorb the integration and maintenance overhead, but the platform still agrees to each MLS's display and licensing rules. Fewer integrations to manage does not mean fewer rules to follow.

IDX providers and listing search widgets

Vendors like SimplyRETS offer turnkey listing search APIs built for developers who want to embed search functionality without managing feed infrastructure. This path is appropriate for agent sites, small broker platforms, or applications where listing display is a feature rather than a core data asset. The access is more constrained than direct or aggregator paths, typically limited to IDX-eligible display data and unsuitable for back-office or analytics use cases. It is the right starting point for early-stage platforms or single-market MVPs, with the understanding that migration to a more robust access layer will be necessary as scope expands.

Third-party REST APIs using non-MLS-licensed data

Scraped or commercially aggregated property data is priced by query volume rather than MLS subscription. The cost is substantially lower, and there is no compliance overhead at the point of access. The tradeoff is data quality in the dimensions that matter most for transaction-facing applications: status changes lag, new listings are absent, and MLS-specific fields are missing entirely. This path is unsuitable for any application where a user makes a transaction decision based on the data. It works for neighborhood research features, AVM inputs where recency matters less than coverage, and market trend visualizations where directional accuracy is sufficient.

What the compliance and licensing layer actually involves in practice

Every MLS data agreement comes with display rules. Attribution requirements: broker and agent name, MLS logo, listing courtesy lines. Data freshness minimums that constrain how long data can be cached. Restrictions on how data can be presented, combined, or repurposed. These rules exist at two levels. NAR's Policy Statement 7.58 establishes the national floor; each MLS then adds its own local requirements on top. The same field can carry materially different display obligations in different markets.

The most common compliance failures are predictable, and they are almost always the result of failing to read the agreement carefully enough before building. Caching listing data longer than the MLS permits. Using sold or off-market data in consumer-facing displays without the appropriate licensing tier. Aggregating data across MLSs in ways that obscure the originating MLS's branding requirements. Applying analytics or AI outputs to MLS data in ways not contemplated by the original license. Each of these is a feed suspension risk, which means they are critical-path risks for any platform whose core user experience depends on listing data being present.

The compliance overhead is the direct reason aggregators like Trestle and MLS Grid exist and command a cost premium. Platforms with limited legal and compliance resources are not paying for aggregators' technical infrastructure alone; they are paying to transfer the compliance maintenance burden to an entity whose primary business is managing it. That is a reasonable trade, but it should be made consciously.

The governance layer is also in motion. RESO Data Dictionary 2.0's April 2024 ratification, combined with the one-year NAR compliance window, means that data contracts negotiated before mid-2025 reference field definitions that MLSs are now certifying against a newer standard. Existing contracts are worth reviewing in that light.

How the vendor and aggregator ecosystem is consolidating, and where it is still fragmented

The MLS count is declining gradually as smaller organizations merge into regional systems. That fragmentation problem is contracting, but at a pace that does not materially change near-term platform strategy. Consolidation belongs in the long-run structural trend column, not the near-term planning column.

On the vendor side, consolidation is more pronounced. A small number of platforms handle a large share of multi-MLS data distribution: Trestle, MLS Grid, Bridge Interactive, and FBS among them. That concentration gives platforms fewer integration relationships to maintain for broad coverage, which is a genuine operational simplification relative to the landscape a decade ago.

MLS Grid's growth to 34 markets and more than 2,200 technology partners reflects the cooperative consolidation model: MLSs retaining local governance while pooling distribution infrastructure. That model is likely to expand because it resolves the tension between local control and operational efficiency without requiring MLSs to surrender either. It is a structurally durable solution to a problem that has resisted purely commercial ones.

But consolidation has firm limits. No single aggregator covers all 500-plus MLSs. Platforms requiring truly national coverage will still need multiple aggregator relationships, a combination of aggregator and direct integration, or an acceptance of coverage gaps. The 7% of MLSs not yet on RESO standards are precisely the hardest markets to reach through aggregators; they require custom integration work by definition. And the local non-standard fields that sit outside the Data Dictionary remain market-specific regardless of which aggregator a platform uses. Consolidation solves the plumbing problem. It does not close the field coverage gap.

One emerging pattern worth monitoring: state-level and regional data sharing agreements among MLSs are creating new access layers in some markets. For platforms focused on specific geographies, these multi-MLS data shares can simplify regional coverage in ways that neither pure direct integration nor national aggregation achieves on its own.

Choosing an access strategy based on what the platform actually needs to do

Geographic scope, use case, and compliance capacity are the three variables that actually determine the right access strategy. Everything else is secondary, and treating secondary variables as primary is how platforms end up with architecturally sound integrations that do not legally permit what the product needs to do.

Narrow geographic focus with full-field requirements points toward direct MLS integration in target markets, supplemented by an aggregator where the aggregator has coverage. The per-MLS negotiation cost is justified by the complete local data access it enables. For a platform building a deep product in one or two markets, this is typically the correct architecture.

Multi-market listing search and display points toward an aggregator relationship as the first move. Trestle, MLS Grid, and Bridge Interactive each cover the most active markets and absorb the compliance maintenance burden that makes direct integration at scale economically irrational. The choice among them depends on which markets the platform prioritizes and what the per-API pricing looks like against projected query volume.

Analytics, AVM, or back-office applications require broker back-office licensing, not IDX. Many aggregators support this use case, but it is a separate agreement from a standard display feed and needs to be confirmed explicitly before the data pipeline gets built. Discovering mid-build that the existing license does not cover the intended use is avoidable; it is also the kind of problem that surfaces at the worst possible time.

Early-stage platforms or single-market MVPs should start with an IDX provider. The barrier to entry is lower, the integration is faster, and the tradeoffs in data depth and flexibility are acceptable at MVP scale. The migration path to a more robust access layer should be planned from the start.

The technology choice, meaning which API or which aggregator, is secondary to the licensing choice. A well-engineered integration sitting on a poorly negotiated license is a liability waiting to surface. The practical starting point is to map target markets, identify which aggregator has the deepest coverage in those markets, confirm that the intended use case is covered by the license tier being offered, and then evaluate the technical integration. That order produces a reliable data strategy. The reverse order produces a rebuild.