Improved Metadata
With RESO Web API version 3, we will no longer deliver a static set of standard fields for every MLS. Every field in the Property payload is guaranteed to be enabled and in use with the MLS.
Additionally, all lookup values for both standard and custom fields are consistently advertised in the Lookup resource.
Support for RESO Data Dictionary v2.0
Version 3 of our RESO Web API uses RESO Data Dictionary v2.0 (DDv2.0). Data shouldn’t be considered fully DDv2.0 compliant until the MLS has its official DDv2.0 certification, and we are still actively working towards this with many of our MLS partners. If DDv2.0 data is important to you, you’ll want to make the transition to version 3. There is no need to wait for the MLS’s DDv2.0 certification before transitioning to our RESO Web API version 3.
Consolidated Custom Field Format
Our RESO Web API version 3 uses a consolidated format for custom multi-select fields, presenting them much more like standard multi-select fields. For example, these four fields in version 2:
"Site_co_Level": true,
"Site_co_Open": true,
"Site_co_PastureField": true,
"Site_co_Wooded": true,
…becomes this single field in version 3:
"Site_co_Site": [
"Level",
"Open",
"Pasture/Field",
"Wooded"
],
The fields are still easily distinguishable as custom fields with human-readable (though not display) names.
Duplicate Custom Fields Removed
When a custom field is mapped to a standard field, we leave the custom field in the payload rather than removing it and disrupting API users who are ingesting the custom field. That leads to some data being duplicated and available as both custom and standard fields. Since version 3 of our RESO Web API contains major breaking changes and requires developers to move to a new endpoint, we are using this opportunity to drop all duplicated custom fields. If a custom field is available as a standard field, we will drop the custom field from the RESO Web API version 3 payload entirely in favor of the standard field.
This is a point-in-time removal of duplicated data. To avoid disruption in the future, we’ll continue to use this same pattern of leaving custom fields in place when they’re newly mapped to standard fields, then dropping the duplicated custom fields with major version updates.
Transition Process
