The RESO Web API standardized listing data across MLSs in 2018, and the standardized payload maps almost 1:1 into RealEstateListing JSON-LD.
- ✓RETS (1999) → RESO Web API (2018) replaced bespoke per-MLS field naming with a RESTful, standardized architecture.
- ✓Data Dictionary 2.0 organizes the standardization through Resources (Property, Member, Office), Fields, and Lookups.
- ✓Multi-MLS brokerages can now ship rich-result-eligible schema across the unified inventory without per-MLS custom mapping.
The RESO Web API patterns that govern schema scalability and rich-result eligibility across every MLS in the inventory.
Pre-2018, every MLS feed required bespoke field normalization for schema generation, which meant a multi-MLS brokerage either shipped inconsistent schema across markets or skipped the schema layer entirely. The 2018 RESO Web API migration changed the picture. The standardized JSON payloads map almost 1:1 into RealEstateListing JSON-LD, and rich-result eligibility becomes a consistent property of the inventory across markets. The four sections below cover what changed, what the Data Dictionary 2.0 actually structures, and where local-market specificity still ships safely.
RETS to RESO Web API: what the 2018 migration actually changed.
The Real Estate Transaction Standard (RETS), launched by NAR in 1999, replaced inefficient FTP transfers but left field naming wildly inconsistent across local MLS markets. SEO and schema work required bespoke normalization per MLS just to generate accurate structured data. The 2018 industry migration to the RESO Web API replaced RETS with a RESTful architecture and standardized the underlying field names through the Data Dictionary. The downstream effect on schema is the consequential one: standardized JSON payloads now map almost 1:1 into RealEstateListing JSON-LD across every compliant MLS, which makes scalable schema generation a property of one ingestion pipeline rather than a per-MLS bespoke build.
Data Dictionary 2.0: Resources, Fields, and Lookups.
The Data Dictionary 2.0 organizes standardized field naming through three layers. Resources are the major data categories: Property (the listings), Member (the agents and members), Office (the brokerages), Media (the photos and virtual tours), and others. Fields are the individual data points within each Resource: ListPrice, BedroomsTotal, BathroomsFull, LivingArea, PropertyType. Lookups are the enumerated value sets bound to fields with restricted vocabulary: the specific fence types, the specific roof materials, the recognized property statuses. The hierarchy is what makes the standardization legible to schema generators on the consuming side and to ranking systems on Google's side.
Property Resource fields that drive rich-result eligibility.
Google's RealEstateListing rich-result eligibility maps to a small set of high-value Property Resource fields. ListPrice for price, BedroomsTotal for beds, BathroomsFull and BathroomsHalf for baths, LivingArea for sq ft, PropertyType for residential / commercial / lease, ListingId for the listing identifier, and the Media Resource entries that ship as the listing image array. datePosted on the listing schema pulls from OriginalEntryTimestamp or ListContractDate, depending on the local MLS convention. Each field has a documented stable name across compliant feeds, which means one schema generator handles every MLS the brokerage ingests from.
Local custom fields and the additionalProperty slot.
Local MLSs extend the standardized dictionary with market-specific custom fields. A coastal MLS adds a Bulkhead boolean, a ski-market MLS adds a SkiAccess enumeration, a desert-market MLS adds a CasitaBedrooms count. The additionalProperty slot on RealEstateListing is the supported pattern for shipping these without breaking the standardized schema. The schema generator checks every field against the RESO Data Dictionary 2.0 field list, routes recognized fields into their standardized slots, and routes anything unrecognized into additionalProperty with the field name and value preserved. The pattern ships local-market specificity cleanly and avoids triggering Google's structured-data parser into validation errors on the local extensions.
What operators ask about the RESO Web API before they evaluate a multi-MLS IDX vendor.
[ 01 ] Why does the RESO Web API matter for SEO and not just for data integration? +
[ 02 ] Which RESO Property Resource fields actually drive rich results? +
[ 03 ] How do we handle the local custom fields that are not in the standard dictionary? +
If the IDX vendor is ingesting from the RESO Web API but stripping the schema layer on render, the rich-result ceiling is set before any retainer work begins. Book an MLS and IDX diagnostic.
We inspect the RESO Property Resource field coverage on the vendor's ingestion, the schema-output sample the vendor generates, the additionalProperty handling for the local custom fields per MLS, and the rich-result eligibility across the unified inventory. Output is the per-MLS field-coverage assessment plus the migration path when the vendor is capping the schema program above the standardized baseline. Funnels into our /mls-idx-seo/ retainer when the work runs deeper than a vendor-evaluation pass.