REALTY-DATA.
Property APIGuides

OData resources

Understand the Property, Media, Member, Office, OpenHouse, and Lookup rollout contract

The RESO service is resource-driven. Each entity set has its own source cursor, primary key, field catalog, checkpointed serving build, and entitlement policy. The service document advertises only resources that have passed all activation gates.

Resource matrix

ResourceCollectionSingle entityIntended keyActivation requirement
Property/Property/Property('ListingKey')ListingKeyActive
Media/Media/Media('MediaKey')MediaKeyPublished media projection and private-media policy
Member/Member/Member('MemberKey')MemberKeySource-key reconciliation, contact-field policy, published build
Office/Office/Office('OfficeKey')OfficeKeySource-key reconciliation, contact-field policy, published build
OpenHouse/OpenHouse/OpenHouse('OpenHouseKey')OpenHouseKeySource-key reconciliation and published build
Lookup/Lookup/Lookup('LookupKey')LookupKeyDataset-specific lookup identity and collision contract

The service document is authoritative

The matrix describes the target product. Call GET /reso/odata to learn which collections are active for the current deployment, then use $metadata for the exact fields and types.

Why entity activation is independent

Property modifications do not prove that an agent, office, open house, media record, or lookup value is current. Every resource is ingested and paged on its own ModificationTimestamp plus stable source key. A resource is activated only after its own replay, deletion, uniqueness, entitlement, and publication checks pass.

Key reconciliation

An upstream schema can identify an entity with a familiar MLS identifier even when the public RESO contract requires a durable resource key such as MemberKey, OfficeKey, or OpenHouseKey. A resource remains unadvertised until uniqueness, collision handling, and direct-key retrieval are proven. The API never silently substitutes a familiar but non-unique identifier.

Common query contract

Activated collections support $select, $filter, $orderby, $top, $skip, $skiptoken, $count, and $ignorenulls. Resource field names are validated against that resource's EDMX catalog. An unknown field returns a bounded OData error before the warehouse query executes.

$expand is not silently emulated. Until relationship-level field entitlements and bounded fan-out are proven, request related resources separately by their keys.

GET /reso/odata/Property?$select=ListingKey,ListAgentKey,ListOfficeKey
GET /reso/odata/Member?$filter=MemberKey in ('agent-1','agent-2')
GET /reso/odata/Office?$filter=OfficeKey eq 'office-1'

Only issue the latter two requests when the service document advertises those entity sets.

On this page