Data ยท 2026-04-01
Migrating Real Estate Data Pipelines from RETS to RESO Web API
The real estate industry spent years running on RETS, the Real Estate Transaction Standard. RETS did its job, but it was never designed for the web-first environment that eventually arrived. RESO Web API is its replacement: RESTful, JSON-based, and built around modern HTTP conventions.
The migration sounds straightforward from the outside. Replace one feed with another. Update the endpoint. Parse JSON instead of RETS responses. In practice, the hard part is not the protocol. The hard part is making sure the listing data your site depends on still arrives, maps cleanly, updates reliably, and displays correctly after the old pipeline is retired.
I have managed this migration for real estate clients with different MLS relationships, data volumes, photo requirements, and display rules. The first lesson is that RETS and RESO do not just differ in transport. They differ in data model. RETS field names often vary by MLS. RESO standardizes field names through the Data Dictionary, but adoption varies. One MLS may provide clean standard fields. Another may expose partial mappings, local extensions, or missing values your old system quietly depended on.
That means every migration needs a real field map. Not a theoretical one. A practical map from the MLS's actual output to the local tables, search filters, templates, and detail pages the site already uses. Bedrooms, bathrooms, acreage, list price, status, property type, open house data, agent fields, office fields, and geocoding all need to be checked against real records.
Photo ingestion is usually where the migration gets more complicated. RETS delivered photos through media endpoints with their own quirks. RESO Web API uses Media resources, but the practical behavior still varies by MLS: rate limits, batch sizes, modified timestamps, retry behavior, ordering, captions, and how deleted photos are represented. I have had to build different ingestion logic for clients on different MLSs even when both were technically using RESO Web API.
Cron architecture matters too. Listing pipelines need to respect API throttle limits while still keeping data current. Polling everything frequently wastes request budget and creates inconsistent freshness. A better approach is to sync around delta detection: pull records changed since the last successful run, store enough local state to know what was updated, and validate record counts before replacing live data.
The safest migration path is a parallel run. Keep the RETS pipeline running while the RESO Web API pipeline builds and populates temporary tables. Compare outputs against the same listings. Check counts, statuses, required fields, photo totals, and representative detail pages. Only cut over when the new pipeline has repeatedly matched expectations.
What looks like a protocol upgrade is really a data architecture project. The clients who handle it smoothly are the ones who understand that before the first line of code changes.