Suppose a search needs price, status, and photographs from several MLSs. RESO’s Data Dictionary supplies shared names and meanings for those pieces of data. A Property record can use ListPrice and StandardStatus; photographs can be represented through Media. The RESO Web API describes how a client requests records and reads metadata.
That common vocabulary reduces translation work. It does not decide which listings a customer may receive or whether every field is populated in a particular feed.
Start with the resource and its metadata
RESO organizes its dictionary as resources, fields, and lookup values. Property, Member, Office, and Media are resources. A field belongs to a resource; a lookup supplies named choices for a field where the standard defines them. The dictionary reference lets a developer inspect the definitions directly.
Before writing a mapping, read the source’s API metadata. Record the resources it exposes, field types, keys, and any local extensions. Then query a small permitted sample across the property classes the product needs. Metadata tells you a field exists; the sample tells you whether the records use it.
Keep a mapping sheet with four columns: source field, RESO meaning, product field, and treatment of an empty or unfamiliar value. A market-specific field may carry information your product needs. Preserve its original name and value for debugging, even if the public interface uses a simpler label.
Treat lookup values as product decisions
A shared StandardStatus field helps a cross-market search, but local practices and feed permissions can affect which records appear. Collect examples of the statuses actually returned by each source. Decide which ones belong in a public “active” filter and test the decision against the MLS’s rules. An unfamiliar value should stay visible to the mapping review rather than quietly entering the nearest bucket.
The same issue appears with property types. A broad residential category may include subtypes the product wants to separate. Build the filter from verified source values, and retain the raw value alongside the normalized one. When a customer reports a missing property, the team can see whether the source omitted it or the application filtered it out.
RESO allows local fields and says full adoption of its more than 1,700 fields is not expected. For each feature and market, list the required fields, permitted records, local mappings, and behavior when data is absent.
AnyProp uses the common schema for its listing API and documents additional features in the Property reference. For example, PreferredMedia returns two photos, giving priority to the preferred image. A search card that needs a small preview can use that expansion; a gallery can request Media.
The reference marks PreferredMedia and PropertyChange as AnyProp extensions. Keep that distinction in the mapping notes. It gives the next engineer both the standard field definitions and the reason a particular screen uses an AnyProp feature.
Query and update deliberately
The Web API specification uses OData features such as filtering, selected fields, paging, and metadata. Follow a server-provided next link when paging; do not assume one response contains the full permitted result set. Store a stable source key so retries update records rather than duplicating them.
Check the source’s change method too. RESO’s EntityEvent specification defines an ordered event resource, but its availability depends on the provider. The application may need incremental polling or another documented route. Test an update and a record that leaves the feed before committing to a refresh promise.
The field list and sample records show whether a proposed filter, report, or display works in a particular market. Keep those findings beside the integration code so the next schema change can be reviewed against a known example.
