The United States does not have one listings database. It has 484 of them, and that single fact is the wall almost every real estate platform hits the week the real data shows up.
Here is the simple version. To show real listings, your platform pulls data from a Multiple Listing Service, the regional system agents use to share inventory. There are 484 of them as of the end of 2025, down from roughly 850 at the 2015 peak, and each one is a separate fief with its own data format, its own field names, its own display rules, and its own update schedule. Your job is to turn that pile of inconsistent regional feeds into one clean, current, deduplicated dataset your product can actually use, and that turns out to be most of the engineering.
The fragmentation is the whole problem
A listings page is easy. Rendering a property card with photos and a price is a first-week task. The reason the data layer is the moat is that the data arrives broken, and keeping it un-broken is permanent work, not a one-time import.
Two MLSs in two states will describe the same kind of property with different field names, different enumerated values for things like property type, and different rules about what you are even allowed to display.
The same listing can show up in your pipeline more than once because a property sits on the boundary of two overlapping MLSs or got re-entered. Feeds go stale, a sync that worked yesterday returns a partial set at 3am, and a listing that closed last week is still sitting in your search because nobody told you it was gone. None of these are exotic edge cases. They are the normal state of MLS data, and a platform that doesn't handle them ships a search full of duplicates and ghosts.
RESO is the standard the industry built to survive this
The good news is that the industry saw the chaos and standardized a way out. The Real Estate Standards Organization defines two things you build around. The RESO Web API is a modern REST interface, OData over JSON with OAuth, that replaced the old RETS feeds the industry ran on for years. The RESO Data Dictionary is the shared vocabulary, a standard set of field names and allowed values that every certified MLS maps onto, so "bedrooms" means bedrooms everywhere.
Get the framing right, because it is a common mistake. The industry moved off RETS and onto the RESO Web API; the policy direction pushed MLSs to support the modern API with data parity, and RETS itself was wound down on the standards side. RESO is the thing that makes integration tractable at all. It does not make it trivial.
Certification means an MLS exposes the dictionary fields, but real feeds still carry local extensions, optional fields that are populated in one market and empty in the next, and quirks the spec doesn't fully pin down. RESO gets you most of the way to one schema. Closing the last gap is your normalization layer.
Normalize once, not on every read
The mistake that melts a real estate backend is normalizing data at read time, transforming and deduplicating listings on every search request. It works in the demo and falls over under load. The pattern that holds is the same one we use in our data-ingestion work elsewhere: do the expensive work once, on the way in, and serve clean data fast.
That means an ingestion pipeline that pulls each feed, maps every local field onto your canonical RESO-aligned schema, resolves duplicates with a stable identity for each real-world property, flags and quarantines records that fail validation instead of letting them poison the index, and tracks freshness so a stale or partial sync is visible rather than silent. It is the same discipline as ingesting messy documents for a production retrieval system: the value is in turning inconsistent source data into one clean, queryable store once, so everything downstream is fast and trustworthy. Build that layer well and the rest of the platform gets easy. Skip it and you pay for it on every feature.
The display rules are a compliance surface
One more thing the generic "just pull the feed" advice misses: what you are allowed to show is governed, not free. Internet Data Exchange, the mechanism that lets a broker display other brokers' listings, comes with rules set by each MLS and by national policy, covering attribution, which listings you may display, refresh frequency, and what you must take down and when. Violate them and you don't get a bug report, you get your data access revoked, which for a real estate platform is the lights going out.
The display logic has to be built to honor those rules per MLS, and that is part of why the data layer is an engineering and compliance problem at the same time.
Build direct or go through an aggregator
You have a real choice about how much of this you own. You can integrate each MLS directly, which gives you the most control and the most maintenance, since every one of those feeds is a relationship and a parser to keep alive. Or you can go through an aggregator that has already done the normalization across many MLSs and exposes one API under one license, the model offered by Bridge Interactive, by CoreLogic's Trestle, and by MLS Grid.
For most teams an aggregator is the right starting point, because it turns hundreds of integrations into one and lets you spend your engineering on the product instead of on feed plumbing. You go direct when coverage, latency, or data rights force it. Either way, the normalization and freshness discipline above is yours to own, because even one clean aggregator feed still lands in your system as data you have to keep correct.
What's still standing in 2028
As MLS consolidation continues, 484 and falling, the data-access chokepoints get narrower and the value of a clean, compliant, well-governed data layer goes up, not down. AI will write the listing copy and power the search box for almost nothing by 2028. It cannot manufacture a correct, deduplicated, current dataset out of broken feeds.
AI cannot manufacture a correct dataset out of broken feeds. That stays human-built engineering, and it stays the part of a real estate platform that is genuinely hard to copy.
FAQ
How many MLSs does a US real estate platform have to deal with? There were 484 Multiple Listing Services at the end of 2025, down from roughly 850 at the 2015 peak. Each is a separate fief with its own data format, its own field names, its own display rules, and its own update schedule.
What is the RESO Web API? A modern REST interface, OData over JSON with OAuth, that replaced the old RETS feeds the industry ran on for years. Alongside it the RESO Data Dictionary provides a shared vocabulary of field names and allowed values, so bedrooms means bedrooms everywhere.
Does RESO certification mean the feeds are actually consistent? No. Certification means an MLS exposes the dictionary fields. Real feeds still carry local extensions, optional fields that are populated in one market and empty in the next, and quirks of their own. RESO makes integration tractable, not trivial.
Should listings be normalized at read time or on ingest? On ingest. Transforming and deduplicating listings on every search request works in the demo and falls over under load. Do the expensive work once on the way in, then serve clean data fast.
What are IDX display rules and why do they matter? Internet Data Exchange lets a broker display other brokers' listings, under rules set by each MLS and by national policy covering attribution, which listings you may show, refresh frequency, and takedown. Violate them and you lose data access, not just a bug report.
Is it better to integrate MLSs directly or use an aggregator? Direct integration gives the most control and the most maintenance, since every feed is a relationship and a parser to keep alive. Aggregators such as Bridge Interactive, CoreLogic's Trestle, and MLS Grid normalize across many MLSs under one API, which suits most teams starting out.
What 2muchcoffee covers
We build the data layer: MLS and RESO Web API integration, the normalization and deduplication pipeline, freshness and validation, IDX-rule-aware display, and the aggregator-versus-direct decision. If your platform is drowning in duplicate or stale listings, or you're staring at a wall of MLS feeds and don't know where the normalization should live, that's the conversation to have before you wire one more feed in by hand. The plain way in is the AI work we do.
One concrete action
Audit your own listing data for one failure: pick a property that should be unique and count how many times it appears in your store, then pick a listing that closed last week and check whether it's still searchable. If you find duplicates or ghosts, that's not a data-cleanup chore, it's a missing normalization layer, and it gets worse with every feed you add. This is one layer of building a real estate platform, and it's the layer the whole product sits on.
