IDX, RETS and RESO Web API Integration for Real Estate

01

What are IDX, RETS, and RESO Web API?

The three terms sit at different layers of the stack. IDX is primarily a licensing and display concept, the rules governing what a broker's site can show and how. RETS was the pre-2020 technical protocol MLSs used to deliver data to those brokers. RESO Web API is the current technical protocol, standardised by the Real Estate Standards Organization, that replaces RETS. Most modern integrations use IDX display rules on top of a RESO Web API data feed. Legacy integrations may still use RETS. Understanding which layer each term operates at removes most of the initial confusion.

Key takeaway

IDX is licensing and display. RETS was the legacy protocol. RESO Web API is the modern protocol. Most 2026 integrations use IDX display rules on RESO Web API data.

02

When to use IDX vs RETS vs RESO

The decision tree is straightforward: is this a new build? Use RESO Web API. Is the target MLS on legacy RETS only? Use RETS but plan a RESO migration path. Are you displaying listings on a broker-owned consumer site? You need an IDX agreement regardless of the underlying protocol. The confusion arises because MLS variability means each board is at a different point in its RETS-to-RESO migration, so a national integration typically has to speak both protocols concurrently for a transition period.

Key takeaway

New builds default to RESO Web API. RETS remains only for MLSs that have not migrated. IDX licensing applies regardless of protocol.

03

The MLS licensing relationship

This is the single biggest surprise for teams new to real estate data. Unlike most industries where you buy an API subscription and get data, MLSs restrict access to licensed real estate professionals and require every consumer of their data to sign a Data Use Agreement with specific display rules. If your business does not hold a real estate license or broker affiliation, you must partner with a vendor that does, or with a broker who sponsors the data access. Building the integration technically is often easier than establishing the licensing relationship.

Key takeaway

MLS access is a licensing relationship first, a technical integration second. Confirm your licensing path before scoping the build.

04

Variations across MLS boards

The dream of a single national feed does not exist. National platforms integrate with dozens or hundreds of MLSs individually, each with its own onboarding paperwork, data quirks, and compliance requirements. RESO has reduced the variation from the pre-standard days but not eliminated it. Practical implications: budget for a data-normalisation layer that reconciles fields across boards, plan for board-specific compliance disclaimers, and expect onboarding timelines to stretch when working across regions.

Key takeaway

Every MLS is a separate integration, even under RESO. Plan for a normalisation layer and board-specific compliance from the start.

05

Architecting the listings layer

Serving listings directly from the MLS feed produces slow searches, breaks when the feed is down, and hits rate limits at scale. The right architecture ingests on a schedule (typically every 15 minutes to hourly), stores the current state in your own database, indexes for fast filtered search, and refreshes the frontend from your own index. This decoupling also lets you enrich the data with proprietary fields (neighbourhood data, walk scores, custom photos) that live alongside the MLS data without polluting it.

Key takeaway

Ingest, normalise, index, serve. Never serve listings directly from the raw MLS feed at scale.

06

IDX vendors vs custom builds

The trade-off is clear. Vendors give you fast time-to-market, licensing handled, but constraints on customisation and per-lead or per-listing pricing that gets expensive at scale. Custom builds give total control but require you to hold or acquire the MLS licensing relationships and build the ingestion and search layer yourself. Most brokerages under 50 agents are best served by vendors. Multi-market operators, portals, and PropTech products with unusual data needs typically build custom by year 2 or 3.

Key takeaway

Vendors for speed and licensing convenience. Custom for control and scale economics. The crossover point is roughly 50 agents or unusual data requirements.

07

Migration from RETS to RESO Web API

The RETS-to-RESO transition has been rolling since 2018 and is expected to be substantially complete by 2027. In the interim, national platforms typically maintain a dual-protocol ingestion layer. When scoping a new integration in 2026, architect for RESO Web API as the primary path and treat RETS as a fallback for laggard boards. The RESO Web API is REST-based, uses OData query syntax, and is materially easier to consume than the older RETS protocol.

Key takeaway

Build RESO Web API first, RETS as fallback. The transition is nearly complete but not universal.

08

Compliance and display-rule gotchas

Common gotchas: showing sold or expired listings without permission, missing the required attribution to the listing broker, caching data longer than the MLS allows, showing photos without the correct copyright attribution, filtering or altering data in ways the MLS restricts. Every integration has to include a compliance review before launch, and every subsequent MLS added has to have its specific display rules audited. This is one of the most common reasons real estate integrations get pulled after launch.

Key takeaway

Display rules are per-MLS. Audit them before launch and again before every board expansion.

09

Cost and timeline

The recurring data cost is often the underestimated line item. A national brokerage integrating with 20 MLSs can spend USD 10-30K per month on data licensing alone before any engineering or infrastructure costs. The onboarding timeline per MLS involves paperwork (Data Use Agreement, IDX participation form), technical setup (RESO endpoint credentials, sandbox testing), and compliance review, all of which move at MLS pace not vendor pace.

Key takeaway

Data licensing is a recurring, per-MLS cost. Budget it explicitly and plan for MLS-paced onboarding timelines.

10

Common integration mistakes

Every mistake traces back to underestimating either the licensing dimension or the per-MLS variation. Teams that plan the licensing path first, architect for multi-MLS variation from day one, budget for recurring data costs, and audit display rules per board avoid the expensive rework that catches unprepared teams after launch.

Key takeaway

Underestimating licensing and per-MLS variation is the single biggest source of failure. Plan for both from the start.