RESO vs RETS: Which MLS Data Standard Should You Build On?

Last updated: June 14, 2026

The RESO vs RETS comparison comes down to a direct verdict for developers: build on the RESO Web API. RETS, the Real Estate Transaction Standard launched in 1999 under NAR and a coalition of industry groups, ran MLS data exchange for nearly two decades and was genuinely effective at scale. By July 2017, WAV Group estimated RETS served 97% of IDX and VOW solutions. But its constraints (a proprietary query language, XML verbosity, and session-based authentication) were products of 1999-era engineering. In June 2017, RESO retired the RETS Workgroup, declared RETS 1.9 the final version, and redirected all certification to the RESO Web API. That standard, built on OData v4, RESTful HTTP, JSON, and OAuth 2.0, is now the mandated transport for REALTOR®-operated MLSs under NAR Policy 7.90, with more than 500 certified MLSs globally as of June 2026. RETS is frozen, and individual MLS boards are shutting it off on their own timelines.

1. RESO vs RETS: A Side-by-Side Comparison
2. What Made RETS Worth Building On
3. How the RESO Web API Works Differently
4. Query Language, Auth, and Media: The Technical Differences
5. Is RETS Feed Obsolete?
6. The RETS Sunset Timeline: Named MLS Examples
7. Developer Decision Guide: What to Build On Now
8. Bringing It All Together
9. Frequently Asked Questions

RESO vs RETS: A Side-by-Side Comparison

The sections below unpack each dimension in detail, starting with query language, authentication, and image handling. A separate section covers why RETS reached this point and what the rolling MLS sunset timeline looks like as of mid-2026.

What Made RETS Worth Building On

Before we bury RETS, give it credit. It launched in 1999, backed by the National Association of REALTORS® and a coalition of industry groups, and solved an ugly problem: before RETS, every MLS spoke its own incompatible dialect of property data. RETS became the industry’s first common exchange language.

It worked at scale, too. Some MLS databases on RETS held 100+ GB of listing data (a figure that traces back to a Mobifilia explainer), and by July 2017 WAV Group estimated RETS served 97% of IDX and VOW solutions. For two decades, if you touched MLS data, you touched RETS. RETS isn’t on its way out because it was badly built; its constraints (proprietary query language, XML verbosity, session auth) are products of 1999-era engineering, not design failures for their time.

How RETS Actually Worked

Here’s what makes RETS feel dated the moment you touch it: it’s stateful. A RETS integration POSTs credentials to a Login URL, gets a session cookie, runs Search requests with DMQL2 query strings, calls GetObject separately for each listing’s images, then hits Logout. That stateful model maps badly to stateless cloud functions and microservices.

DMQL2 (Data Mining Query Language 2) sits at the center of it, proprietary to real estate, with no support in any modern REST library.

How the RESO Web API Works Differently

The RESO Web API is the replacement, and it’s the work of an actual standards body. RESO, the Real Estate Standards Organization, was incorporated as an independent nonprofit in November 2011, according to Constellation Data Labs. If you want the full certification breakdown (tiers, compliance timelines, and how the two standards interlock), RESO standard explained covers it.

What matters for your build is the stack. The RESO Web API runs on OData v4 (the Open Data Protocol), RESTful HTTP, JSON, and OAuth 2.0. None are real estate inventions; they’re open standards used across Microsoft Dynamics, SAP, and more, so the libraries already exist in your language.

NAR Policy Statement 7.90 required REALTOR®-operated MLSs to implement the RESO Data Dictionary by January 1, 2016 and the RESO Web API by June 30, 2016. Per RESO’s certification figures, as of June 2026 more than 500 MLSs across the U.S., Canada, and beyond hold RESO certification.

RESO Is Actually Two Standards

Here’s the distinction that trips people up: “fully RESO” means two standards are in place. The RESO Data Dictionary defines what field names mean and what values are allowed, ending the cross-MLS field fragmentation that plagued RETS. The RESO Web API defines how data moves.

An MLS can hold a Web API certification without a high Data Dictionary alignment score, so check both via RESO Analytics at certification.reso.org, where Data Dictionary certification has tiers you can compare per MLS. Per WAV Group’s reporting, Data Dictionary 2.0 passed in April 2024 with an April 2025 deadline for NAR-affiliated MLSs; DD 2.1 is in draft.

Query Language, Auth, and Media: The Technical Differences

This is where the comparison stops being abstract. Three differences show up in your codebase on day one: the query language you write, how you authenticate, and how you fetch listing photos.

DMQL2 vs OData: The Query Language Change

RETS queries use DMQL2, a proprietary language no REST client understands. The RESO Web API uses OData $filter expressions, the same operators any OData service speaks. Same request, active listings at or above $200,000:

# RETS DMQL2 query: active listings at or above $200,000
(ListingStatus=Active)AND(ListPrice=200000+)

# RESO Web API OData equivalent
/Property?$filter=StandardStatus eq 'Active' and ListPrice ge 200000

# RESO Web API bulk replication via timestamp filter
/Property?$filter=ModificationTimestamp gt '2024-01-01T00:00:00Z'

Two things changed. ListingStatus became StandardStatus, a standardized RESO Data Dictionary field name that reads the same across every certified MLS, and DMQL2’s parenthetical syntax became OData’s readable eq, ge, and and operators. That third line matters too: a timestamp filter on ModificationTimestamp gives you the same batch-sync pattern RETS used, so the RESO Web API is not real-time-only. MLSImport uses this timestamp-filter pattern for its hourly listing sync.

Authentication: From Session Login to Bearer Token

RETS makes you babysit a session. You POST credentials to a Login URL, store the returned cookie, send it with every Search and GetObject request, then call Logout. Any timeout means a re-login, which breaks inside a cloud function or auto-scaling service.

The RESO Web API is stateless. You obtain an OAuth 2.0 access token (via the client credentials or authorization code grant), then send it as a Bearer token in the Authorization header on every request. No cookies, no Logout, no sessions to time out. It runs natively on AWS Lambda, Cloudflare Workers, or any REST framework.

📌 Pro Tip: Before you wire a production credential set into anything, ask your MLS vendor for sandbox or test credentials. Validate your OAuth flow and field mappings against throwaway data first, so a typo in your token handling never touches the live feed.

Image Retrieval: GetObject vs the Media Resource

Photos are the difference nobody writes about. Under RETS, every listing image meant a separate GetObject HTTP request inside the session, with image type and object ID as parameters. Under the RESO Web API, photos are a Media resource, a standard OData entity you query like anything else: GET /Media?$filter=ResourceRecordKey eq ‘12345’. They’re filterable and pageable, so there’s no special-case image code.

Is RETS Feed Obsolete?

Yes, at the standards level RETS is obsolete. RESO, the Real Estate Standards Organization, announced RETS 1.9 as the final version of the standard in June 2017, retired the RETS Workgroup, and stopped issuing RETS certifications by approximately 2018 (the exact month appears only in secondary sources). The RESO Web API, built on open internet standards, is now the mandated and actively certified replacement.

On June 23, 2017, at the RESO Spring Summit, RESO retired the RETS Workgroup after its final 1.9 release. Paul Stusiak, then chair of the RESO RETS Workgroup and president of Falcon Technologies, put it this way: “I think everybody has come to understand that the focus for the future is on the Web API. And if a member comes up with a critical (RETS-related) problem, the board can still decide to charter a new workgroup to deal with that particular problem.”

Cary Sylvester of Keller Williams, a RESO officer, gave the analogy that still fits best: “RETS is not dead, because it’s not dead until you quit using it. But we are not going to extend it further. We are going to focus on the RESO Web API.” And the line worth pinning above your desk: “Think about it like (Adobe) Flash. It’s no longer developed, but it’s still running, and a lot of people still keep running it. And that’s okay.”

RESO’s own Web API page confirms RETS “has been deprecated and is no longer supported by RESO.” The “June 2018” certification-end date circulates only in secondary sources, not a primary RESO post, so treat the year as solid and the month as unconfirmed. NAR Policy 7.90 makes the phase-out non-optional: REALTOR®-operated MLSs must serve the RESO Web API.

The RETS Sunset Timeline: Named MLS Examples

The “is rets being discontinued” question has a precise answer, and it’s not a single date: there’s no industry-wide off switch. RESO and NAR set the mandate and certification structure; each MLS operator picks its own RETS sunset date.

Take RLCAR MLS (the Rideau-St. Lawrence and Champlain regions). Per its official announcement page, RLCAR began retiring RETS in October 2022 and set a hard cutoff of March 31, 2024, directing developers to the Spark platform afterward. After that date, RETS access to RLCAR data was gone. That’s the clearest primary-source rets sunset date in the wild.

Bigger names have finished too. MRED (Midwest Real Estate Data), one of the largest U.S. MLSs, appears in the “Completed 100% Web API Transition” table on RESO’s June 2026 Leaderboard, meaning its RETS endpoint is retired. WAV Group reported that WARDEX MLS, on CoreLogic’s Trestle platform, became the first U.S. MLS to earn RESO Data Dictionary 2.0 certification in October 2024. Reporting from repliers.com also describes TRREB (Toronto Regional Real Estate Board) migrating from RETS to a new RESO Web API-based platform called PropTx.

The macro numbers come from the RESO Web API Transition Leaderboard, as of June 2026: 90%+ of U.S. MLSs hold a RESO-certified Web API, feeds covering roughly 62% of U.S. subscribers are fully converted, and about 76% sit under MLSs committed to conversion, up from under 5% in 2021. The Leaderboard reports both figures but does not explain the spread; the most likely read is that smaller MLSs certified ahead of the largest-subscriber ones, so subscriber coverage still trails certification.

Developer Decision Guide: What to Build On Now

So what do you do? Two scenarios. New integration: build on the RESO Web API, never a line of RETS. Migrating off RETS: the work is real but bounded, and the sooner you start, the less you’re racing a shutdown notice. For example, MLSImport RESO support connects to your MLS through the RESO Web API, with no RETS integration required.

How to Check Your MLS’s Status

1. Check the RESO Web API Transition Leaderboard at reso.org/web-api-transition-leaderboard. If your MLS sits in the “Completed 100% Web API Transition” table, RETS access may already be off. For technical connection specs once you’ve confirmed your MLS’s RESO status, see RESO Web API connection details.
2. Check your MLS vendor’s news and announcements page for a published RETS shutdown notice. Official notices are the only reliable source of MLS-specific dates.
3. Contact your MLS’s technical support directly and ask for the current RETS status and whether a sunset date has been announced.

What Changes When You Migrate

1. Auth flow: replace digest session login and its session-management code with an OAuth 2.0 client credentials grant and a bearer token on each request.
2. Query syntax: replace DMQL2 query strings with OData $filter expressions (the DMQL2 vs OData block above is your reference).
3. Response format: replace XML parsing with JSON parsing.
4. Image retrieval: replace per-image GetObject calls with a single Media resource query.

Budget the most time for the Data Dictionary field-name remap: fields like ListingStatus become StandardStatus, and every MLS-specific custom field mapping has to be re-evaluated, one feed at a time.

📌 Pro Tip: The field-name remap isn’t only an import-layer job. When ListingStatus becomes StandardStatus, that rename ripples into your front-end templates, search facets, and saved-search filters too. Grep the whole codebase for the old field names before you call the migration done.

Bringing It All Together

Here’s the part that turns this from a someday project into a this-quarter one: if your MLS already sits in that “Completed 100% Web API Transition” column, this isn’t a future migration. Your RETS endpoint is already gone, and any integration still pointed at it is broken or about to be. The RESO vs RETS question was settled at the standards level in 2017; the only open variable now is your MLS’s specific cutover date. Check the Leaderboard before assuming you have runway.

If you’ve already moved a RETS integration over to the RESO Web API, we’d love to hear how it went, especially how long the Data Dictionary field-name remap took once front-end templates and search facets were in scope. Drop your experience in the comments so the next developer knows what to budget.

Frequently Asked Questions

Is RETS completely dead?

No, but it depends what you mean. At the standards level, yes: RESO stopped extending and certifying RETS starting in 2017. At the infrastructure level, some MLS servers still run RETS endpoints. Cary Sylvester’s 2017 framing fits best: RETS is like Adobe Flash, abandoned by its maker but still running where nobody migrated. Tools like MLSImport skip RETS entirely and connect through the RESO Web API.

Can I start a new RETS integration today?

Technically yes, if your target MLS still serves a RETS endpoint. Practically, no. Any new RETS build will need a migration once your MLS announces its sunset date, so you’d be coding toward a known dead end. Start on the RESO Web API instead. MLSImport, for one, connects over that standard, so there’s no RETS layer to rip out later.

Does the RESO Web API only support real-time queries?

No, that’s a common misconception. The RESO Web API fully supports bulk replication through OData timestamp filters such as $filter=ModificationTimestamp gt ‘2024-01-01T00:00:00’, the same batch pattern RETS used, just with JSON output and standardized field names. MLSImport uses exactly this replication approach to sync listings on an hourly cycle. Real-time queries are an option, not a requirement.

How do I know if my MLS has already shut off RETS?

Start with the RESO Web API Transition Leaderboard at reso.org/web-api-transition-leaderboard. If your MLS sits in the “Completed 100% Web API Transition” table, RETS access has likely been retired. If it’s listed as committed but not completed, check your provider’s announcements page for a cutoff date. When in doubt, contact MLS technical support, or use a tool like MLSImport that already runs on the RESO Web API.