What Is the RESO Web API for Real Estate Development Teams?

The RESO Web API is a RESTful, OData V4-based protocol for real estate data exchange. It delivers property data over HTTPS in JSON format. This article explains how it works at the implementation level, covering protocol mechanics, OData queries, authentication, MLS use cases, and best practices for development teams. It’s a technical follow-up to the Hicron Software blog post on RESO Standards. If you need a foundation in what RESO Standards are and why they matter, you should start there first. 

Key Takeaways: 

• The RESO Web API uses OData V4 as its query layer. Reading the $metadata endpoint first is the correct starting point for any integration. 

• OAuth 2.0 and HTTPS are the required authentication and transport standards. Legacy RETS credential models do not apply here. 

• Replication relies on ModificationTimestamp for incremental updates. Provider behavior varies even among RESO-certified MLS systems. 

• RETS is deprecated. The RESO Web API represents a different operational model, not an upgraded version of the same thing. 

The RESO Web API replaced RETS as the industry standard for real estate data exchange because RETS had fundamental architectural limitations. RETS was built around bulk XML downloads and basic credential-based authentication. It required heavy local storage and created ongoing lag between source updates and data availability. As MLS organizations grew in scale and data complexity, those limitations became increasingly costly to manage. 

The Real Estate Standards Organization (RESO) introduced the Web API to address these limitations directly. The protocol standardizes how systems request, filter, and receive property data across MLS organizations. Rather than downloading large batches of XML and processing them locally, development teams can now query live data using structured OData parameters over HTTPS. The result is a more efficient, maintainable, and interoperable integration model. 

For development teams migrating from RETS or building new integrations from scratch, understanding how the RESO Web API works at the protocol level is the most practical starting point. So let’s learn more about OData integration, endpoint structure, pagination, replication, authentication, and the implementation challenges teams face in real-world projects. 

What Is the RESO Web API?

The RESO Web API is a RESTful data transport standard built for real estate data exchange. It delivers property data over HTTPS in JSON format, using OData V4 as its query and metadata layer. RESO maintains and certifies the standard across MLS organizations. The governing document is the RESO Web API Core 2.0.0 Specification, published by the RESO Transport Workgroup. Certification confirms that an MLS provider’s implementation meets core specification requirements. For development teams, this sets a baseline for expected API behavior.

That baseline, however, does not guarantee uniform behavior across providers. Field availability, pagination defaults, and rate limiting rules are common areas where implementations diverge. Teams working across multiple MLS systems need to account for this variability from the start. 

Core 2.1.0 is currently in development. Some providers have already begun adjusting endpoint behavior, particularly around how the $top parameter is handled. Reviewing provider-specific changelogs before assuming consistent behavior across RESO-certified systems is a practical step before beginning any integration work. 

What Is OData and Why It Matters in Practice?

OData (Open Data Protocol) is a standardized protocol for building and consuming RESTful APIs. RESO selected OData V4 as the foundation for the RESO Web API due to its broad tooling support, cross-platform interoperability, and availability of client libraries across multiple languages. 

OData controls more than how data is requested. It also defines how clients discover what data is available. This distinction has practical implications. Before writing any queries, a developer uses OData’s metadata endpoint to understand the full data structure exposed by a given provider. This positions OData as central to the integration process from the very first step. 

The key OData concepts that appear throughout this article are: 

• $filter: Filters result sets by field values 

• $expand: Includes related resources in a single request 

• $metadata: Returns the full schema of available fields and types 

• @odata.nextLink: Provides the URL for the next page in a paginated result set 

• $select: Limits the fields returned in a response 

• $top: Sets the maximum number of records per response 

• $skip: Offsets the result set for pagination 

• $orderby: Sorts results by a specified field 

Understanding these parameters is the foundation of any RESO Web API integration. 

How the RESO Web API Works at a Protocol Level

The RESO Web API exposes real estate data through standardized resource endpoints. Each resource represents a specific entity type, such as a property listing, a real estate agent, or a listing photo. Requests follow a consistent URL structure and return JSON responses. Metadata is the exception, as it returns in XML format. The sections below cover each protocol component in detail, starting with available resources and working through metadata, querying, pagination, and replication. 

What Are the Core Resources Available in the RESO Web API?

The RESO Web API exposes the following core resources: 

• Property: Listing data including price, status, features, and location 

• Member: Agent and contact information 

• Office: Brokerage and office details 

• Media: Photos, documents, and videos associated with listings 

• OpenHouse: Scheduled open house events 

• Room: Room-level detail records linked to properties 

• Unit: Unit-level records for multi-unit properties 

Endpoints follow a consistent structure. A typical endpoint for property data looks like this: 

GET /Reso/OData/Property 

A basic request with an Authorization header would be structured as follows: 

GET /Reso/OData/Property HTTP/1.1 
Host: api.example-mls.com 
Authorization: Bearer {access_token} 
Accept: application/json 

The exact base URL varies by provider, but the resource path structure follows the specification. 

What Does the RESO Web API Metadata Endpoint Return?

The $metadata endpoint returns the full Entity Data Model (EDM) for a given provider. This includes all available fields, their data types, and enumerated lookup values. It is the authoritative source for understanding what data a specific MLS provider exposes. 

GET /Reso/OData/$metadata

Metadata is returned in XML format. All other API responses use JSON. The metadata document defines standard fields from the RESO Data Dictionary, along with any provider-specific extensions. Custom fields typically follow a naming convention that distinguishes them from standard fields. This convention varies across providers. 

Reading $metadata before writing queries reduces errors. It prevents issues caused by referencing fields that do not exist or have unexpected data types. 

How to Filter and Query RESO Web API Data Using OData

The RESO Web API supports the following OData query parameters for filtering and shaping responses: 

A basic filtered query requesting active listings looks like this: 

GET /Reso/OData/Property?$filter=StandardStatus eq 'Active

To include related media records in the same request, use $expand: 

GET /Reso/OData/Property?$filter=StandardStatus eq 'Active'&$expand=Media

The $expand parameter is particularly valuable for listing photo pipelines. Without it, a developer would need one request per property to fetch associated media records. This pattern is known as an N+1 request problem. Using $expand retrieves the property record with its related media in a single request. 

The same approach works for open houses: 

GET /Reso/OData/Property?$expand=OpenHouse

Custom fields added by individual MLS providers use encoded field names. Cross-referencing these names in the $metadata document reveals their human-readable equivalents and data types. 

How Does Pagination Work in the RESO Web API?

Pagination in the RESO Web API uses $top and $skip for offset-based navigation. For larger data sets, the API returns an @odata.nextLink property in the response. This contains the URL to retrieve the next page of results. 

{
 "@odata.nextLink": "https://api.example-mls.com/Reso/OData/Property?$skip=200",
 "value": [...]
}

Following @odata.nextLink until it no longer appears in the response is the correct approach for full data pulls. 

The behavior of $top varies across providers. Some enforce a maximum page size regardless of the requested value. Others apply default limits when $top is omitted. As Core 2.1.0 adoption increases, some providers are adjusting their $top handling. Always check provider documentation before assuming a specific page size behavior. 

How Does Data Replication Work with the RESO Web API? 

Replication with the RESO Web API follows a two-phase model. The first phase is an initial full pull of all available records. The second phase uses ModificationTimestamp to fetch only records that have changed since the last sync. 

An incremental update request looks like this: 

GET /Reso/OData/Property?$filter=ModificationTimestamp gt 2024-01-15T00:00:00Z&$orderby=ModificationTimestamp asc

Spark Platform’s RESO replication documentation provides a worked example of how one provider structures this process. This is one provider’s implementation. Replication patterns, field availability, and sync limits vary by MLS provider even among RESO-certified systems. Field names, available resources, and pagination defaults will differ.

Teams building replication pipelines should plan for provider-level variation from the start, rather than assuming that behavior tested against one MLS will transfer directly to another. 

What Is RESO Web API Authentication and Security: OAuth 2.0, HTTPS, and Token Management?

Securing API access is a core part of any RESO Web API integration. The protocol requires OAuth 2.0 for authentication and HTTPS for all data transport. These requirements apply consistently across RESO-certified providers. Token management, scope configuration, and rate limiting vary by provider. Understanding how the authentication flow works is essential before building any production integration. This is especially true for long-running jobs, where token expiry and re-authentication can cause failures. 

How Does OAuth 2.0 Authentication Work in the RESO Web API?

The RESO Web API uses OAuth 2.0 as its authentication and authorization standard. OAuth 2.0 provides secure, delegated access without exposing long-lived credentials directly. It is the same framework used across major technology platforms, which means development teams can use familiar libraries and tooling. 

The general flow for obtaining access is: 

1. Register a client application with the MLS provider to receive a client ID and secret 
2. Request an access token from the provider’s token endpoint 
3. Include the token in the Authorization header of all API requests 

Authorization: Bearer {access_token}

The authorization scope granted at token issuance determines the level of data access the client receives. Providers may issue tokens with read-only access, limited resource access, or full access depending on the license agreement and terms of use. 

All API requests require HTTPS (TLS). Providers do not support unencrypted connections. This is a consistent requirement across RESO-certified systems. 

Legacy RETS authentication relied on basic username and password combinations, sometimes with simple bearer tokens. These were often long-lived and difficult to revoke. OAuth 2.0 improves on this model by offering token expiration, scope restrictions, and access revocation without rotating credentials. 

Token management requires attention in long-running replication jobs. Access tokens expire. Systems should implement refresh token logic or automated re-authentication to maintain uninterrupted data access. Rate limiting and throttling rules vary by provider and are often applied per token. Teams building replication workflows should plan for throttle responses and implement retry logic with appropriate backoff strategies. This connects directly to the implementation challenges covered in the next section. 

What Are Key Differences Between RESO Web API and RETS?

RETS is deprecated. RESO no longer updates its specifications, and many MLS providers have already shut down their RETS endpoints. The comparison below focuses on technical implications for development teams, not the business case for migration. 

The core architectural difference is the shift from batch XML downloads to live JSON queries. RETS required teams to download large data sets locally, then parse and store them. The RESO Web API allows systems to request exactly the data they need, when they need it. 

What Are Common MLS Integration Use Cases for the RESO Web API?

MLS data serves a wide range of applications, from consumer property searches to backend analytics platforms. Each use case places different demands on how data is queried, stored, and refreshed. The following examples outline how organizations apply MLS integration in practice: 

What Is an IDX Property Search Feed?

IDX (Internet Data Exchange) search platforms query active listings directly from MLS providers. The RESO Web API supports live queries against the Property resource, filtering by status, location, price range, and other criteria. Consumer-facing portals benefit from this because they can request fresh listing data on demand rather than relying on a cached local data set. 

How Does Full Data Replication Support Analytics and Valuation?

Teams building automated valuation models or market analytics platforms typically require a complete local copy of MLS data. The RESO Web API replication model supports this through initial full pulls followed by incremental updates via ModificationTimestamp. Keeping a local data set current requires consistent polling and reliable token management. 

How Does Open House Synchronization Work?

The OpenHouse resource exposes scheduled open house events linked to property records. Spark Platform’s OpenHouse documentation provides an example of how one provider implements this resource. Teams building agent tools or consumer apps can sync open house schedules using the same OData filtering patterns applied to property data.

How Are Member and Office Directories Integrated?

The Member and Office resources expose agent and broker contact data. CRM platforms and agent-matching tools use these resources to keep directory information current. The same incremental update pattern used for property replication applies here. 

How Are Listing Photo Pipelines Structured for Media Retrieval?

The Media resource provides structured access to listing photos and associated metadata. Using $expand=Media on a Property request retrieves both the listing record and its associated photos in a single call. For high-volume photo pipelines, this approach reduces total API requests and simplifies pipeline logic. 

What Are Common RESO Web API Integration Challenges?

Several challenges appear consistently across RESO Web API integrations. Understanding these early reduces delays and prevents rework later in the development cycle: 

• Field mapping gaps between the RESO Data Dictionary and local MLS extensions. Not every provider maps all standard fields from the RESO Data Dictionary. Some fields will be missing. Others will be present but populated inconsistently. 

• Metadata variance across RESO-certified providers. Two providers can both hold RESO certification and still expose different fields, different enumerated values, and different endpoint behaviors. The $metadata document for each provider is the authoritative source. Assumptions built from one integration do not carry forward. 

• Custom fields outside the core RESO Data Dictionary. Providers frequently add non-standard fields to meet local requirements. These fields appear in $metadata but are not part of the RESO Data Dictionary. Custom field names often use vendor-specific prefixes. Teams need a field mapping process that accounts for these extensions. 

• Pagination limits and rate throttling. Maximum page sizes and rate limits differ across providers. Some impose hard caps well below what teams expect. A replication job that works efficiently against one MLS may hit throttle limits immediately on another. 

• Token expiration in long-running replication jobs. Access tokens expire. A replication job running for hours without re-authentication logic will eventually fail. Building token refresh or re-authentication into the replication workflow is necessary for stable operation. 

• Sandbox environments that do not reflect production. Provider sandbox environments often contain partial data or differ from production in field availability, pagination behavior, and rate limits. Testing in a sandbox reduces risk but does not eliminate the need for careful validation against production. 

What Are Best Practices for RESO Web API Integrations?

Teams working with RESO Web API connections often encounter the same failure points: undocumented field changes, inconsistent pagination, and authentication timeouts. Following a structured set of guidelines reduces the risk of these issues appearing in production environments. The practices below apply across provider types and integration architectures, drawing from real integration challenges observed across MLS providers, PropTech platforms, and brokerage systems: 

1. Read $metadata first. Every integration starts with a request to the provider’s $metadata endpoint. This reveals available fields, data types, and enumerated lookups before any other queries are written. 
2. Build a field mapping table aligned to the RESO Data Dictionary. Map each provider’s fields to their RESO Data Dictionary equivalents. Document custom fields separately. This table becomes the foundation for any data normalization logic downstream. 
3. Use ModificationTimestamp as the primary sync mechanism. For incremental updates, filter by ModificationTimestamp rather than pulling full data sets repeatedly. Store the timestamp of the last successful sync and use it as the filter value on the next run. 
4. Use $select to limit payload size. Requesting only the fields required for a specific use case reduces response size and processing time. Avoid requesting all fields when only a subset is needed. 
5. Use $expand deliberately. Expand related resources within a single request when those resources are consistently needed together. Reserve $expand for cases where it reduces total request volume, not as a default behavior for every query. 
6. Validate data using the RESO Commander testing tool. The RESO Commander is an open-source testing tool published by RESO. It validates provider implementations against the specification and helps teams identify issues before building production integrations. 
7. Plan for provider-level variation. Treat each RESO-certified MLS provider as a distinct integration target. Build abstraction layers in the codebase that allow provider-specific behavior to be configured without rewriting core logic. 
8. Monitor provider changelogs. Providers adopting Core 2.1.0 may change $top handling and other endpoint behaviors. Subscribing to provider update communications prevents unexpected behavior from breaking live integrations. 

How Can You Build Better Real Estate Integrations with Hicron?

The RESO Web API gives development teams a structured, well-documented protocol for building reliable real estate data integrations. The implementation details covered here, from OData query construction to replication workflows and OAuth token management, represent the practical knowledge needed to move from specification to production. Hicron Software works with PropTech teams and real estate software companies on MLS integrations, RETS migration projects, and data pipeline architecture. If you or your team is evaluating a move to the RESO Web API or is encountering specific integration challenges, contact Hicron to discuss the project requirements.