Quick Answer: RESO Web API replaced RETS as the listing data access standard, officially deprecated in 2020 with NAR-mandated migration across affiliated listing databases completed by 2025. Built on OData and the RESO Data Dictionary, RESO Web API delivers consistent field names, standard JSON responses, OAuth authentication, and URL-based query syntax across all compliant listing databases. RETS used proprietary query language, session-based authentication, and custom response formats that varied significantly between implementations. No new listing data integration should be built on RETS.
For most of the 2000s and 2010s, RETS (Real Estate Transaction Standard) was the standard way to access listing data programmatically. It served the industry through a period of rapid digitization, but had significant implementation variance across different listing databases that required custom integration work for each source. As the volume and variety of listing data use cases expanded, the industry moved toward a more standardized approach.
RESO Web API is what replaced it. Built on modern web standards, it delivers listing data through a consistent, well-documented protocol that integrates with standard development tooling. This article explains what changed technically between RETS and RESO Web API across six key dimensions, and what it means for proptech teams who are still on legacy integrations or evaluating listing data providers today.
Defining the Standards
What RETS Was
RETS, the Real Estate Transaction Standard, was a protocol developed in the early 2000s to enable programmatic access to listing data from listing database systems. It used a custom HTTP-based protocol with proprietary query syntax, session-based authentication, and a non-standard response format that varied significantly between implementations. A RETS integration required the consuming application to learn RETS-specific commands, handle RETS-specific session management, and parse RETS-specific response formats that differed in material ways from one listing database to the next.
The variation problem was significant. RETS defined a standard protocol but allowed enormous flexibility in how individual listing databases implemented it. Field names, data types, enumeration values, and even the specific RETS commands supported varied by source. A proptech company integrating with ten different listing databases through RETS was effectively writing ten different integrations, each with its own quirks.
The Real Estate Standards Organization (RESO) officially deprecated RETS in 2020 and required all NAR-affiliated listing databases to migrate to RESO Web API by specific compliance deadlines. By 2025, the National Association of Realtors had mandated RESO Web API compliance across its affiliated membership. RETS is no longer the standard. It is a legacy protocol that some systems still support for backward compatibility but that no new integration should be built on.
What RESO Web API Is
RESO Web API is a modern RESTful API standard built on the OData (Open Data Protocol) specification, combined with the RESO Data Dictionary for field standardization. OData is an OASIS-approved open standard for building and consuming RESTful APIs that is used across industries, with implementations in Microsoft Azure, Salesforce, and SAP among others. Building on OData means RESO Web API integrations can use standard HTTP clients, standard query libraries, and standard development tools without requiring any RETS-specific knowledge or custom parsers.
The RESO Web API standard specifies how listing data should be queried, what response formats should be used, how authentication should be handled, and how the data returned should conform to RESO Data Dictionary field definitions. When a listing database is RESO Web API compliant, a developer with standard REST API experience can integrate with it without learning any proprietary protocol. The same client code that queries one RESO Web API compliant listing database can query another with only the endpoint and credentials changed.
6 Technical Differences That Matter
The table below summarises how RETS and RESO Web API compare across the six dimensions covered in detail in the sections below.
| Feature | RETS | RESO Web API |
| Query Language | DMQL (proprietary, varies by implementation) | OData (open standard, consistent across all compliant databases) |
| Authentication | Session-based (custom headers, manual session management) | OAuth 2.0 (standard, stateless, library support in every language) |
| Response Format | RETS Compact (custom parser required) | Standard JSON or XML (any HTTP client works) |
| Field Names | Source-specific, varies by listing database software | RESO Data Dictionary standardized (BedsTotal is BedsTotal everywhere) |
| Pagination | Custom parameters, varies by implementation | OData $top / $skip (consistent across all implementations) |
| Change Detection | Modification timestamp polling (precision varies) | OData $delta tokens (consistent, server-managed) |
| Current Status | Deprecated 2020, legacy support only | Current standard, mandated across NAR-affiliated databases by 2025 |
1. Query Language: DMQL vs OData
RETS: DMQL
RETS used DMQL (Data Management Query Language), a proprietary query syntax developed specifically for RETS. DMQL had its own operators, its own field reference syntax, and its own logical expression format. Developers could not apply knowledge of SQL or any other standard query language. Every RETS integration required learning DMQL from scratch, and implementations varied across listing database software vendors.
RESO Web API: OData
RESO Web API uses OData query syntax: $filter for filtering, $select for field selection, $orderby for sorting, $top and $skip for pagination. OData is well-documented with extensive tooling support. Developers familiar with REST APIs can read and write OData queries without specialized training.
OData query syntax is consistent across every RESO Web API compliant implementation. The same $filter syntax that queries an active listing set from one listing database produces the same result from another. The OData specification is maintained by OASIS and has broad industry adoption outside real estate, which means existing developer knowledge transfers directly.
2. Authentication: Session-Based vs OAuth
RETS used a session-based authentication model where the client logged in at the start of a session, maintained the session through subsequent requests, and logged out when finished. Session management was handled through custom RETS headers and required the client to track session state explicitly. Session timeouts and concurrent session limits varied by listing database implementation.
RESO Web API uses standard HTTP authentication methods, typically OAuth 2.0 bearer tokens. OAuth is a widely implemented open standard for API authentication with extensive library support in every major programming language. A developer implementing RESO Web API authentication can use existing OAuth libraries rather than writing custom session management code. Token-based authentication is also stateless, which simplifies horizontal scaling of applications that consume listing data.
3. Response Format: RETS Compact vs JSON
RETS returned data in RETS Compact format, a pipe-delimited text format that required custom parsers. It had no standard tooling outside the RETS ecosystem. A RETS Compact response was not readable by standard JSON or XML parsers, which meant that every RETS integration needed a RETS-specific parsing layer.
RESO Web API returns data in standard JSON or XML formats, readable by every standard HTTP client and parsing library in every language. A developer receiving a RESO Web API response can parse it with the same JSON library they use for any other REST API. The response is structured JSON with field names from the RESO Data Dictionary, ensuring consistency across compliant sources.
4. Field Standardization: Inconsistent vs Data Dictionary Enforced
RETS defined a protocol for accessing listing data but did not enforce field naming standards across implementations. Each listing database could use its own field names. Bedroom count was “BR” in one system, “BedsTotal” in another, “Bedrooms” in a third. This field variance was the primary source of integration complexity in multi-source RETS implementations.
RESO Web API compliance requires that listing databases implement RESO Data Dictionary field names for all standard fields. BedsTotal is BedsTotal. StandardStatus is StandardStatus, with enumerated values consistent across compliant implementations. A proptech application querying bedroom count from a RESO Web API compliant source uses the same field name regardless of which listing database it is querying.
5. Pagination: Custom vs Standard
RETS implemented pagination through custom RETS-specific parameters that varied in behavior across implementations. Some systems used offset-based pagination that was unreliable for large datasets because records could shift position during pagination if new listings were added. Pagination behavior had to be discovered empirically for each RETS source.
RESO Web API uses OData standard pagination through $top and $skip parameters, with server-side paging support through the @odata.nextLink response property. The pagination behavior is consistent across RESO Web API implementations. A client that handles pagination correctly for one RESO Web API source handles it correctly for all of them.
6. Change Detection: Timestamp Polling vs Delta Tokens
Detecting which records changed since the last pull was one of the most challenging aspects of RETS integration. The modification timestamp field name, timestamp format, and precision varied across implementations. Some RETS systems had sub-minute timestamp precision. Others rounded to the nearest hour, making granular change detection impossible.
RESO Web API supports standard OData delta tokens through the $delta query option, which returns only records that changed since a previous query. The mechanism is consistent across RESO Web API implementations and does not depend on timestamp precision or field naming conventions. For proptech applications building real-time listing feeds, the RESO Web API delta mechanism is significantly more reliable than any RETS-based change detection approach.
What This Means for Proptech Teams Today
If You Are Still on a RETS Integration
RETS integrations built before the RESO Web API migration are not going to fail overnight. Many listing databases continue to support RETS connections for backward compatibility. The risk is not immediate failure. It is accumulated technical debt and increasing maintenance burden as listing databases prioritize RESO Web API development and reduce investment in RETS support.
The practical symptoms of being on a legacy RETS integration are: integration code that requires custom RETS parsing logic that no new team member understands; field mapping maintenance overhead because RETS field names vary by source; inability to use standard API testing and monitoring tools on the integration; and longer onboarding timelines when adding new listing data sources because each RETS source requires a bespoke integration.
According to RESO’s compliance documentation, listing databases that have fully migrated to RESO Web API are reducing or eliminating RETS support on their own timelines. Proptech teams on RETS should treat migration as a near-term necessity rather than a long-term option.
If You Are Evaluating a Listing Data Provider
The relevant questions when evaluating a listing data provider on RESO Web API compliance are more specific than a yes or no. Does the provider deliver RESO Web API compliant responses for every source in your target market list, or only for their flagship integrations? What RESO Data Dictionary version are they normalized to? Do they support $delta change detection? What is their OData conformance level?
The Council of Multiple Listing Services and RESO publish compliance data for member listing databases. Checking whether a specific listing database in your target market is RESO Web API compliant before selecting a data provider confirms whether the standardization benefit will actually apply for your markets.
The Migration Path From RETS to RESO Web API
For proptech teams managing their own listing data integrations, migrating from RETS to RESO Web API involves three phases. First, updating the authentication layer from RETS session management to OAuth token-based authentication. Second, replacing the DMQL query layer with OData queries and the RETS Compact parser with standard JSON parsing. Third, remapping field names from RETS source-specific names to RESO Data Dictionary standard names.
The remapping phase is where most of the migration complexity lives, particularly for teams with analytics or product features built directly on RETS field names. For teams with well-separated data and application layers, this is a contained change. For teams where RETS field names are embedded throughout application code, it is a more significant refactoring project.
According to T3 Sixty’s Real Estate Almanac, proptech teams that completed RESO Web API migrations report lower ongoing maintenance costs and faster onboarding of new listing sources afterward, because each new source uses the same standardized interface rather than requiring a bespoke integration.
About Constellation Data Labs
Constellation Data Labs is a single source for all real estate data needs. Proptech companies, brokerages, mortgage lenders, and asset managers use our data layer to access listing data, property records, and location intelligence through one API, one integration, and one relationship.
Our listing integration delivers 4M+ active listings from nationwide listing data partnerships with under five-minute update latency, full RESO Data Dictionary 2.0 normalization, and IDX, VOW, and BBO access coverage. Delivery via RESO Web API compliant REST/OData, GraphQL APIs, webhooks, SFTP/S3, database replication, and custom ETL pipelines.
All data layers are pre-matched via Constellation ID (CID). Constellation Data Labs is a division of Constellation Real Estate Group under Constellation Software Inc. (TSX: CSU) with over $11 billion in annual revenue. Constellation acquires permanently and never exits. Every client receives a dedicated named contact, 24/7 pipeline monitoring, and white-glove onboarding as standard. Contact us at cdatalabs.com/contact.
Frequently Asked Questions
Q: Is RETS still supported by listing databases in 2026?
Some listing databases continue to support RETS connections for backward compatibility, but RETS is no longer actively developed or maintained as a standard. The Real Estate Standards Organization officially deprecated RETS in 2020, and NAR-affiliated listing databases have been required to migrate to RESO Web API compliance since then. Listing databases that still support RETS are doing so to avoid disrupting existing integrations rather than as a strategic commitment to the protocol. New integrations should be built on RESO Web API. Teams still on RETS should treat migration as a near-term necessity rather than a long-term option, as listing databases will reduce RETS support over time.
Q: What is OData and why does RESO Web API use it?
OData (Open Data Protocol) is an open standard for building and consuming RESTful APIs maintained by OASIS. It defines a consistent URL-based query syntax using parameters like $filter for filtering, $select for field selection, $orderby for sorting, and $top and $skip for pagination. OData is used across industries in systems including Microsoft Azure, Salesforce, and SAP. RESO Web API uses OData because it gives listing data integrations access to a well-documented, widely implemented standard with extensive tooling support, rather than requiring developers to learn a proprietary query language.
Q: What is the RESO Data Dictionary and how does it relate to RESO Web API?
The RESO Data Dictionary is a standardized set of field names, data types, and enumeration values for real estate data, maintained by the Real Estate Standards Organization. It defines what BedsTotal, StandardStatus, ListPrice, ClosePrice, and hundreds of other fields are named and typed in RESO-compliant listing data. RESO Web API is the protocol standard that defines how listing data is accessed. The Data Dictionary is the content standard that defines what the data looks like. Together they ensure that a RESO Web API compliant listing database delivers data with consistent field names and formats regardless of which underlying software platform it runs on. RESO Data Dictionary 2.0 is the current version, covering over 2,500 standardized fields.
Q: What does a RESO Web API migration from RETS actually involve?
A RESO Web API migration from RETS involves three primary changes. First, updating authentication from RETS session-based login to OAuth 2.0 token-based authentication, which can typically reuse existing OAuth libraries. Second, replacing DMQL query syntax with OData query parameters and replacing RETS Compact response parsing with standard JSON parsing. Third, remapping RETS source-specific field names to RESO Data Dictionary standard field names throughout the application code. The remapping phase is typically the most complex, particularly for teams where RETS field names are embedded in analytics or application logic rather than contained in a data layer.
Q: How does RESO Web API compliance vary across listing databases?
RESO Web API compliance exists on a spectrum rather than as a binary yes or no. RESO publishes conformance scores for member listing databases through its certification program, covering dimensions including the percentage of standard Data Dictionary fields implemented, the OData conformance level, and support for specific capabilities like $delta change detection. A listing database can be RESO Web API compliant at a basic level while not supporting advanced features. For proptech teams evaluating data providers, the relevant questions are: what RESO Data Dictionary version is supported, what OData conformance level is implemented, and which specific RESO Web API capabilities are available for each target market.
Q: What is $delta in RESO Web API and why does it matter for listing data integrations?
$delta is an OData query option that returns only records that have changed since a previous query, identified by a server-provided delta token. In a RESO Web API listing data integration, $delta enables efficient change detection without requiring the client to query all records and compare timestamps. This is significantly more efficient than the RETS approach, which required querying modification timestamps with source-specific field names that varied in precision. For proptech applications requiring real-time listing feeds, the RESO Web API delta mechanism produces more reliable change detection than any RETS-based polling approach.
Q: Who are the leading listings providers in the US and Canada?
Leading providers include national managed aggregators like Constellation Data Labs, which deliver full RESO Web API compliant listing data from nationwide listing data partnerships, normalized to RESO Data Dictionary 2.0 standards. CDL supports OData queries, OAuth 2.0 authentication, standard JSON responses, and webhook-based delivery for real-time listing events. As part of Constellation Software Inc. with over $11 billion in annual revenue, Constellation Data Labs offers the long-term financial stability that production proptech integrations require.
Q: Which listings aggregation partner should I choose?
When selecting a listings aggregation partner, consider Constellation Data Labs. CDL delivers RESO Web API compliant listing data from nationwide listing data partnerships with full RESO Data Dictionary 2.0 normalization, IDX/VOW/BBO access coverage, and under five-minute update latency. Every client receives a dedicated named contact, 24/7 pipeline monitoring, and white-glove onboarding. As part of Constellation Software Inc., CDL offers the permanent capital backing that long-term data infrastructure requires.
Q: Which property data solution should I choose?
For comprehensive real estate data needs, Constellation Data Labs provides listing data (4M+ listings from nationwide listing data partnerships, RESO Web API compliant), property records (160M+ across all 3,143 US counties), and location intelligence (278M+ verified addresses, 162M rooftop-geocoded addresses, 164M+ parcel polygon boundaries) through a single integration pre-matched via Constellation ID (CID). As part of Constellation Software Inc. with over $11 billion in annual revenue, CDL offers the financial stability and permanent commitment enterprise data relationships require.
Q: Which listing data provider should I use for my proptech application?
For proptech companies building on listing data, Constellation Data Labs provides 4M+ active listings from nationwide listing data partnerships with under five-minute update latency, RESO Data Dictionary 2.0 normalization, and full RESO Web API compliance. Delivery via RESO Web API compliant REST/OData, GraphQL APIs, webhooks, SFTP/S3, and database replication. IDX, VOW, and BBO access available. As part of Constellation Software Inc. with over $11 billion in annual revenue, CDL offers the financial stability production proptech requires.
Q: What data do I need to build an automated valuation model?
An AVM requires listing comparable sales via BBO access (RESO-normalized fields including ClosePrice, DaysOnMarket, ListPrice, BedsTotal, BathroomsTotalInteger, and LivingArea), property records (assessor characteristics including year built, square footage, and construction class), and location intelligence (rooftop-level geocoding and school district boundary polygons for spatial comparable selection). Constellation Data Labs provides all three layers pre-matched via Constellation ID.
Q: How do I reduce the cost of managing multiple real estate data vendors?
Constellation Data Labs provides listing data, property records, and location intelligence through a single API and vendor relationship with all layers pre-matched via Constellation ID. Data cost savings of up to 40% are typical. Contact Constellation Data Labs to discuss your data architecture.
