RESO retired RETS and the industry has moved to the Web API. We map your RETS classes and fields to the RESO Data Dictionary, run the new sync beside the old one, and switch when the numbers match.
RETS Login user + UAGetMetadata classes, lookupsfields to ListPrice, StandardStatus$filter=ModificationTimestamp gt {last}RETS sync offMost IDX plugins and custom code from the RETS era broke, or will break, when the feed ends. The site stays up but the listings freeze, then go stale. Moving early means you pick the date, not your MLS.
RETS, the Real Estate Transaction Standard, launched in 1999 as the common way for MLSs to hand listing data to brokers and vendors. It was built for copying data: you logged in, searched with DMQL queries, and downloaded the results into your own database.
In 2017 RESO released RETS 1.9 as the final version and retired the RETS workgroup. RESO no longer supports or extends it. Its standards and certification work moved to the RESO Web API.
The Web API runs on OData over plain HTTP, with OAuth tokens and field names from the RESO Data Dictionary. Some MLSs have already switched RETS off and serve data only through APIs. Others still run it, on their own timeline.
Your RETS login does not carry over. Web API access is a separate request, usually to the same MLS or its vendor.
Ask whether it serves the Web API directly or through a platform like Trestle, Bridge, MLS Grid or Spark, and whether there is a date for the RETS shutdown.
Request the same use you have on RETS, such as IDX or VOW, so the fields and statuses line up with what your site shows today.
A new data licence or platform contract is common, even with the same MLS.
You receive OAuth client credentials or a bearer token and an endpoint, in place of the RETS username, password and user agent.
Keep the RETS login live until the Web API sync has been checked against it. Then the RETS credentials are retired.
The listings are the same, but almost every part of how you get them changes.
01RETS used DMQL, its own query language. The Web API uses OData, so a filter looks like $filter=ListPrice gt 500000.
02RETS used a login session with a username, a password and often a user agent. The Web API sends an OAuth or bearer token with each request.
03RETS GetMetadata described each feed's own classes and fields. The Web API's $metadata describes resources that follow the Data Dictionary.
04RETS split listings into classes the MLS named, such as residential or land. The Web API has one Property resource, with property type as a field.
05RETS photos were downloaded through GetObject calls. The Web API returns a Media resource with a URL for each photo.
06RETS paged with offsets and the feed's own modified field. The Web API follows @odata.nextLink and filters on ModificationTimestamp.
Things that only show up once a feed has run for a few months. We learned them on a multi MLS platform we built and ran from 2018 to 2025.
Each RETS feed names its classes, fields and lookup values its own way. We read the metadata and write the map down before any code changes.
RETS photos have to be downloaded. We run them through a queue and only fetch again when the photo timestamp changes.
We map RETS fields onto RESO names first, so the old and new feeds land in the same schema and can be compared row by row.
Incremental RETS pulls query the feed's own modified date field. The Web API side uses ModificationTimestamp. Both track the last value they saw.
Most RETS era sites run an IDX plugin. If the plugin vendor supports your MLS on the Web API, an update may be all it takes. If not, the sync moves out of the plugin into a server cron job that fills its own tables, and the theme reads those.
The old RETS command and the new Web API job write into the same listing schema, so both can run on the scheduler at once and be compared. When counts and prices agree, the RETS job and its client library come out of the project.
Custom RETS code is often a nightly script built on a RETS client library. It is replaced by a scheduled HTTPS sync that follows nextLink and tracks ModificationTimestamp. Your pages keep reading the same tables, so the front end barely changes.
Your listings never go blank. The new sync runs beside whatever feeds the site today, and we only switch when the two match.
We list the classes, fields and photos your site reads today and check your Web API access.
The Web API sync runs beside the RETS one, writing into the same schema.
Listing counts, prices, statuses and photos checked between the two feeds.
The site reads from the new sync. The RETS job and its credentials go.
There are three ways off RETS. If your IDX plugin vendor supports the Web API for your MLS, an update may be enough. If you have custom code that works, moving the sync to the Web API and keeping the rest is often the smaller job.
A rebuild makes sense when the RETS code is old, nobody knows how it works, or the site needs features it never had. The audit tells you which of the three fits before you spend anything.
Your site's address, what it runs on, and which MLS or feed you have access to.
Access, fields, photos, rosters, and how your platform stores listings.
What syncs, how often, what shows where, and a fixed price for the build.
If you go ahead, the $499 comes off the integration.
We are an independent developer. We are not affiliated with, or certified by, any MLS or data provider named on this page.
Send the site's address and the feed you have access to. The audit gives you a written plan and a fixed quote.