"We need MLS integration" sounds like one requirement. It's actually three separate decisions bundled into one sentence, and most budget overruns on real estate platforms trace back to one of those three being underestimated or skipped entirely.
We haven't shipped a named real estate case study yet, and we won't claim one we don't have. What we can speak to honestly is where MLS integration scope actually goes wrong, because it's the first real conversation with any real estate client evaluating a build.
Key takeaways
- RESO Web API (REST, JSON, OData) is the current MLS integration standard as of 2026. RETS is deprecated, and a new build starting on RETS is starting on a standard already being phased out.
- IDX integration is the single most underestimated line item in real estate software quotes: in one 600-project dataset, the original IDX budget was off by more than 40% in 64% of projects.
- MLS integration is not one decision, it's three: how many markets to cover, how deep the data requirements go, and how much licensing complexity the team can absorb, each one changes the real cost.
- RESO's Data Dictionary 2.0 normalizes field names across different MLSs. Skip that normalization step and multi-market listings will not reliably compare against each other.
01The standard changed, and a lot of guidance online has not caught up
RESO, the Real Estate Standards Organization, sets the data standards the MLS industry actually runs on. As of 2026, RESO Web API, built on REST, JSON, and OData, is the current standard for direct MLS integration. RETS, the older standard a lot of existing guides and tutorials still reference, is deprecated, and a new integration built against it is starting on infrastructure already being phased out.
RESO's Data Dictionary 2.0 is the other half of this that gets skipped constantly: it standardizes field names, ListPrice, StandardStatus, LivingArea, so listing data from different MLSs actually maps to one schema instead of each source using its own inconsistent field names.
64%
Share of projects where the original IDX budget was off by more than 40%, per a specific 600-project dataset (Homesage.ai)
MLS integration is not one decision, it's three, bundled into one sentence.
02The three decisions hiding inside "we need MLS integration"
How many markets you need to cover changes everything downstream. A single-market integration is a materially smaller project than one covering ten-plus markets, where licensing and data normalization complexity compound fast. How deep your data requirements go matters just as much: a basic listing search needs far less than an analytics or AI pipeline built on top of the same feed.
How much licensing complexity your team can actually absorb is the decision most often skipped entirely. Every MLS has its own licensing terms, and a platform touching several markets is managing several sets of terms simultaneously, not one.
03What we build
Integration scoped against RESO Web API from the start, not RETS, so the build isn't inheriting a standard already being phased out. Data Dictionary 2.0 normalization built in, so multi-market listings actually compare against each other correctly instead of silently drifting apart on field naming.
A real answer, before any commitment gets made, to which of the three decisions above actually applies to your project, market count, data depth, licensing complexity, because that combination is what determines the real scope and cost, not a single "MLS integration" line item.
04What not to do
Don't start a new integration against RETS because an older tutorial or a previous vendor's codebase still uses it. That's building against a standard already on its way out, and it will need replacing sooner than a RESO Web API build would.
We haven't built integrations across every regional MLS's specific licensing terms. If your target markets have unusual licensing requirements, raise that early, before scoping, not after.
05Getting started
Name your actual market count and data depth requirements before requesting a quote. "MLS integration" without those two numbers is not a scopeable requirement.
Ask any vendor directly whether they're building against RESO Web API or RETS. If the answer is RETS, ask why, given RETS is deprecated.
Budget for the Data Dictionary normalization work explicitly. It is not automatic, and skipping it is exactly where the underestimation this post opened with tends to happen.
Frequently asked questions
Generally no for a new build. RETS is deprecated in favor of RESO Web API. If you're inheriting an existing RETS integration, migrating it is worth planning for, but starting new work on it means building against infrastructure already being phased out.
Because 'MLS integration' gets treated as one line item when it's actually three separate decisions, market count, data depth, licensing complexity, each with its own cost driver. One specific 600-project dataset found the original IDX budget off by more than 40% in 64% of projects, largely from this underestimation pattern.
Naming your real market count and data depth requirements, then scoping licensing complexity for each target MLS before writing integration code. Those three answers determine the real cost, not a single generic quote.