What Are IDX, MLS, RETS and the RESO Web API?

You’ve probably heard all four terms in the same meeting. Your broker mentions IDX, your MLS vendor mentions RETS, and a developer quotes the RESO Web API. They sound related. They are, but they’re four completely different things, and confusing them will cost you weeks of integration time.

Here’s the short version: MLS (Multiple Listing Service) is the regional broker cooperative and listing database. IDX (Internet Data Exchange) is the NAR-governed policy that lets licensed participants display MLS listings on their own websites — a rulebook, not a feed. RETS (Real Estate Transaction Standard) was the XML-based data protocol for nearly 25 years; RESO officially deprecated it in 2018. The RESO Web API is the modern REST/JSON replacement, built on OData v4, and the current industry standard.

This guide is for two audiences at once. Realtors get the plain-language paragraph at the start of each section. WordPress developers get the technical depth that follows.

MLS: The Regional Database That Everything Else Builds On

An MLS is not a website. It’s not Zillow, Realtor.com, or any portal you can pull up in a browser. It’s a membership-based cooperative run by and for licensed real estate brokers, and it holds the regional listing database the rest of the industry builds on top of.

The cooperative structure is the point. Brokers who compete head-to-head for clients agree to share their listings with each other through the MLS. Without it, every brokerage would have to negotiate listing access bilaterally with every other brokerage.

How many are there? Just over 500 in the US as of July 2025, plus more than 30 in Canada, according to RESO’s MLS FAQ. The number used to be over 1,000; regional consolidation has been chewing through the smaller MLSs for years. The same FAQ documents that MLSs were first created in the late 1800s, long before computers. They started as in-person sharing, then index cards, then printed MLS books, then online databases. The cooperative model has not changed.

One piece of housekeeping. Zillow, Realtor.com, Homes.com, Coldwell Banker’s site, and Redfin are not MLSs. They’re advertising portals and brokerage sites that receive listing data from MLSs through IDX and syndication agreements. RESO’s FAQ puts it directly: “These are popular websites that get some of their listing data from MLSs, but they are not MLSs themselves.” The MLS is the source; the portals are the storefront.

For developers, the MLS is something you almost never touch directly. You’ll work through a vendor platform (Bridge, Trestle, Spark, or Paragon, covered later) which authenticates against the MLS and exposes the data through a standardized API. The MLS sets the rules, which get enforced through the RETS or RESO Web API endpoints managed by the vendor.

Every MLS historically maintained its own field-naming conventions. list_price in one MLS could be LP in another and ListingPrice in a third. The RESO Data Dictionary was created specifically to fix that.

IDX: The Permission Framework, Not a Format

IDX is not a data format. It’s not a protocol, not software, not a feed. IDX stands for Internet Data Exchange, and it’s a legal-policy framework that determines who can display MLS listings on their website and under what conditions.

Governance comes from two layers. NAR (the National Association of REALTORS) sets the minimum standards through Policy Statement 7.58, adopted May 2000. Each local MLS writes its own IDX rules that meet or exceed NAR’s minimums; local rules can be more restrictive, never looser. The NAR IDX Background and FAQ documents the full revision history; the policy has been amended a dozen times, most recently at NAR NXT in November 2025, effective January 1, 2026.

The November 2025 amendment matters. NAR removed the optional local provision that limited IDX display rights to REALTORS only. Non-REALTOR licensed brokers in many markets now have clearer IDX access rights.

What does IDX participation actually require for a realtor? Four things, in order: be a licensed broker who is an MLS participant (or an agent under one), sign the MLS’s IDX agreement, follow the display rules (brokerage name visible, attribution present, expired listings removed promptly, no commingling of listings from different MLSs without disclosure), and maintain “actual control” over how the data is displayed.

Now the developer clarification, because this is where most of the industry confusion lives. When someone says “set up an IDX feed,” they actually mean “obtain the right to use MLS data (the IDX agreement) and then access it via RETS or RESO Web API (the technical plumbing).” IDX is the permission. RESO Web API is the transport. Different layers.

A developer does not implement IDX. The broker does, by signing the IDX agreement with the MLS. The developer implements the RETS or RESO Web API feed under the umbrella of the broker’s IDX permission. A “WordPress IDX plugin” listing in the plugin directory does not grant IDX rights; it displays MLS data using credentials obtained under an IDX agreement the broker already has.

RETS: The Legacy Protocol That Ran Real Estate for 25 Years

RETS launched in 1999, when XML was the internet’s currency and RESTful APIs didn’t yet exist. For 25 years it was the only way to pull listing data out of an MLS. It’s now end-of-life.

RETS stands for Real Estate Transaction Standard. NAR and related organizations launched it in 1999 as the first technical protocol that let software retrieve listing data from an MLS in a consistent way. For nearly two decades, every IDX website and MLS-connected app ran on RETS underneath.

That ended in 2018. RESO’s own Web API page states it plainly: “It has been deprecated and is no longer supported by RESO.” The retirement timeline accelerated through 2024. MLSImport’s analysis documents that at least one major vendor shut off RETS integrations on December 31, 2024. Paragon-platform MLSs are the most likely place a developer will still encounter RETS in 2025 and 2026, but even there the writing is on the wall.

If you’re a realtor and your MLS vendor is still mentioning RETS in 2026, ask them what their RESO Web API endpoint looks like and what their retirement timeline is. You don’t want to invest in plumbing that’s about to be capped off.

The technical anatomy. RETS uses an XML-RPC-style request/response pattern over HTTP, with five core transactions. Login authenticates with HTTP Digest or Basic auth (not OAuth) and returns a session cookie. GetMetadata returns an XML schema. Search executes a DMQL2 query and returns XML. GetObject pulls binary data (photos, documents) in a separate call per listing. Logout ends the session. Source: NAR’s RETS page.

A DMQL2 example, the query language RETS uses:

(Status=|A)
(ListPrice=100000+)

That’s the rough equivalent of WHERE Status = 'Active' AND ListPrice >= 100000. Status in this MLS could be StandardStatus in another. The same query could fail against a different MLS with a different set of valid status codes.

Why RETS is painful in modern stacks:

• XML parsing for every response, no native JSON
• Session-based auth (HTTP Digest or Basic), stateful and breaks behind load balancers without sticky sessions
• DMQL2 is proprietary and MLS-specific; what works against one MLS may not work against another
• Photos require separate GetObject transactions per listing
• No OAuth, no token refresh, no modern security primitives
• Field names were not standardized across MLSs before RESO’s Data Dictionary, so cross-MLS queries were essentially impossible

RETS 1.7.2 and 1.8 are the most commonly encountered in production; 1.9 technically exists. RESO no longer updates or supports RETS at any version.

RESO Web API: The Modern Standard

The RESO Web API is what RETS should have been. A stateless REST/JSON API built on open standards, with OAuth2 security and a shared field-name contract that makes the same query work across hundreds of different MLS systems.

RESO stands for Real Estate Standards Organization, an independent nonprofit incorporated in November 2011 after starting as a NAR workgroup around 2000. RESO governs two things: the Data Dictionary (the field-name contract) and the Web API (the transport specification). For a realtor, this means your MLS’s vendor exposes listing data through a modern API that works the same way across MLS systems. Ask whether their endpoint is production-ready, not just certified on paper.

The current ratified spec is RESO Web API Core 2.0.0, published by the RESO Transport Workgroup. It’s built on OData v4, an OASIS standard widely used outside real estate. The format is REST/JSON for every endpoint except $metadata, which returns XML. Authentication uses OAuth 2.0 with the client credentials grant.

The two-layer structure is the key concept. Sam DeBord, CEO of RESO, framed it cleanly in a May 2025 article in RealEstateNews.com: “The Data Dictionary defines common data field names and types, the Web API provides a consistent way for data collaborators to request and respond to data transport needs.” Dictionary is the contract. Web API is the pipeline.

Data Dictionary fields every developer hits in the first five minutes of integration:

• ListingKey: unique identifier, used as primary key in OData
• StandardStatus: closed enumeration with values Active, Pending, Closed, Expired, ActiveUnderContract, ComingSoon. Vendors cannot add custom values, which is what makes cross-MLS search possible.
• ModificationTimestamp: DateTimeOffset in UTC, used for incremental sync
• ListPrice: current asking price
• Media: related resource for photos, accessed via a separate endpoint or via $expand

The OData query you’ll write the first time you sync listings:

GET /Property?$filter=StandardStatus eq 'Active'
    and ModificationTimestamp gt 2026-01-01T00:00:00Z
    &$top=200
    &$orderby=ModificationTimestamp asc
Authorization: Bearer [access_token]
Accept: application/json

Translation: fetch up to 200 active listings modified since January 1, 2026, oldest first. In a real sync you replace the date with your last successful sync timestamp and run this on a cron. The Bearer token came from a prior OAuth2 client-credentials POST. If the response includes @odata.nextLink, follow it; otherwise use $top and $skip.

Same job in RETS as pseudocode:

1. POST /Login with username/password → session cookie
2. POST /GetMetadata → XML schema of available fields
3. POST /Search?Query=(Status=|A) → XML payload of matching listings
4. POST /GetObject?Type=Photo&ID=[ListingKey] → photos, one call per listing
5. POST /Logout → end session

Five session-dependent calls, XML at every step, separate photo fetches per listing. Same job in RESO Web API:

1. POST /oauth/token (client_id + client_secret) → reusable Bearer token
2. GET /Property?$filter=StandardStatus eq 'Active'&$expand=Media → JSON with photos inline
3. Follow @odata.nextLink if present

One auth call, one data call (paged if needed), JSON throughout, stateless. The same result that took five session-bound XML transactions in RETS now takes one OAuth handshake plus one paginated query.

Adoption is real but uneven. Sam DeBord reported in May 2025 that “93% of the approximately 500 MLSs in the U.S. are already certified on RESO standards.” The Data Dictionary 2.0 deadline added pressure: RESO passed DD 2.0 in April 2024, and by mutual agreement every MLS affiliated with NAR was required to certify within one year. WAV Group’s Victor Lund reported that WARDEX MLS, on CoreLogic’s Trestle platform, was the first US MLS to achieve RESO DD 2.0 certification, in October 2024. Wardex CEO Kim Everett: “Having good data is important, but clean, standardized data allows all consumers to work quickly and easily to integrate with our system.”

The trust caveat. RESO-certified means an MLS has passed RESO’s tests. It does not mean every RETS endpoint has been shut off, or that every developer-facing implementation is production-hardened.

The Four Side-by-Side: How MLS, IDX, RETS and RESO Web API Relate

The four terms live at different layers of the same stack. MLS is the database, IDX is the access policy, RETS is the old cable, and RESO Web API is the fiber line that replaced it.

RETS and RESO Web API both deliver listing data that falls under the IDX permission framework. People call the data feed “the IDX feed” when they mean “the RETS or RESO Web API credentials used under an IDX agreement.” That conflation is the root of most of this confusion.

The Vendor Layer: Where Developers Actually Get Their Credentials

Here’s a detail most documentation skips. When you go looking for RESO Web API credentials, you almost never call your MLS directly. Your MLS uses one of a handful of vendor platforms that manage the data feed on its behalf. You contact your MLS, get IDX approval, and your MLS points you to its vendor. The vendor issues OAuth2 client credentials and an API endpoint. The RESO Web API is the standard. The vendor is the door.

Four major vendor platforms cover most of the US market.

Bridge Interactive (Zillow Group). API base at api.bridgedataoutput.com. Owned by Zillow Group. Bridge holds RESO Web API Platinum Certification at version 1.0.2. Auth is OAuth2 Bearer token. RESO’s own assessment describes Bridge’s implementation as mapping to the Data Dictionary “with the least amount of data loss.”

Trestle (CoreLogic, rebranding to Cotality). Documentation lives at trestle-documentation.corelogic.com. The API base is migrating from api-trestle.corelogic.com to api.cotality.com before the end of 2025. Support email is now [email protected]. WARDEX (the first US MLS to certify on RESO DD 2.0) runs on Trestle. CoreLogic offers a sample feed via the Austin Board of Realtors for initial testing.

Spark API (FBS / Flexmls). RESO Web API v3 endpoint at replication.sparkapi.com/Version/3/Reso/OData/. FBS serves more than 120 MLS organizations. FBS’s CEO Michael Wurzer is RESO Board of Directors Vice Chair, which means the company is simultaneously a major MLS platform and a standards body leader. FBS introduced the first RESO-compliant listing API back in 2011.

Paragon (Black Knight / ICE Mortgage Technology). Help portal at pahelp.paragonrels.com. Paragon still publishes its RETS Best Practice Guide v2.1 (October 2023), which tells you something. Victor Lund’s October 2024 WAV Group analysis explicitly named Paragon as a vendor needing to accelerate RESO Web API migration. Most MLSs on Paragon do offer RESO Web API access, but the transition timeline has been slower than Trestle and Bridge.

Which vendor you use is your MLS’s choice, not yours. Contact your MLS, confirm IDX approval, and ask which vendor they use. Then go to that vendor’s documentation to register and obtain client credentials. Most vendors offer a sandbox or sample feed before you request production access, which is the pattern you want, because debugging against live MLS data while you’re still figuring out OData is a quick way to get your credentials suspended.

if you want to find you more you can read this guide: mls website for realtors.

Common Confusions Debunked

Before you talk to an MLS vendor or start an integration, clear up these four confusions. They’re pervasive and they will send you in the wrong direction.

“IDX is a data format or feed technology.” The truth: IDX is NAR Policy Statement 7.58, a legal-policy framework governing who can display MLS listings and how. The underlying technology is RETS (legacy) or RESO Web API (modern). IDX is the permission. RESO Web API is the plumbing. Source: NAR IDX Background and FAQ.

“RETS and RESO Web API are interchangeable, use whichever works.” The truth: RESO officially deprecated RETS in 2018. RESO.org states plainly that “It has been deprecated and is no longer supported by RESO.” At least one major vendor shut off RETS integrations on December 31, 2024, per MLSImport. For any new build in 2025 or 2026, RESO Web API is the only viable path.

“MLS = Zillow (or Realtor.com, or Redfin).” The truth: Zillow, Realtor.com, Homes.com, and Redfin are advertising portals that receive listing data from MLSs through IDX and syndication agreements. They are not MLSs. RESO’s FAQ: “These are popular websites that get some of their listing data from MLSs, but they are not MLSs themselves.”

“Every MLS now has RESO Web API, you can always use it.” The truth: 93% of US MLSs are RESO-certified, but “certified” means they passed RESO’s tests. It doesn’t mean every RETS endpoint has been retired or every vendor implementation is production-hardened. Paragon-platform MLSs were named by industry analysts (WAV Group’s Victor Lund, October 2024) as a place where adoption has lagged. Verify with your specific vendor’s documentation.

How This Looks on a WordPress Real Estate Site

All the policy, protocol, and standards discussion above resolves into a practical question for anyone building a WordPress real estate site. How do listings from an MLS database actually end up on a property page in a browser? The answer is a five-step chain.

1. MLS database: the source of truth. Your broker is a member and enters listings there.
2. IDX agreement: the broker signs the MLS’s IDX agreement, which grants the right to display MLS listings on their website.
3. Vendor API credentials: the MLS’s vendor (Bridge, Trestle, Spark, or Paragon) issues OAuth2 client credentials and a RESO Web API endpoint URL.
4. Import / sync layer: a scheduled process (a plugin or custom code) authenticates against the vendor API, pulls listings modified since the last sync using ?$filter=ModificationTimestamp gt [last-sync-timestamp], and writes them into WordPress as Custom Post Type (CPT) records.
5. WordPress theme: the CPT records are rendered as property listings, single-property pages, search results, and map views.

Step 4 is where the field-mapping work lives. Each RESO Data Dictionary field has to land in a WordPress post meta key the theme already understands.

Without a theme that already understands property data, the developer has to build CPTs, search filters, map integration, agent profiles, and single-property templates from scratch before writing a line of sync code. That’s weeks of work before you’ve moved a single listing.

The real estate WordPress theme WPResidence addresses this by shipping the property schema already in place. The CPTs, post meta keys, search UI, map integration, and agent profile templates are pre-built. WPResidence does not bundle an MLS feed itself; you pair it with an import layer. MLSImport, which covers more than 800 RESO-compliant MLS boards across the US and Canada, pulls listings via RESO Web API and maps RESO Data Dictionary fields to WPResidence’s existing property meta keys. The developer’s job shrinks from “build a real estate platform” to “wire up the data pipeline.”

Third-party IDX widget plugins (such as iHomefinder or dsIDXpress) take a different approach. Listings live in a separate database, often inside an iframe, and the theme’s search, map, and agent features do not apply. Only listings imported as actual WordPress CPT posts are fully addressable by theme features. That’s why most serious real estate WordPress sites pick a CPT-based import flow over a widget-based display flow.

Frequently Asked Questions

Is RETS still used in 2026?

RESO officially deprecated RETS in 2018 and no longer updates or supports it. Several major vendors shut off RETS integrations in late 2024. Most new MLS integrations now use the RESO Web API. If you encounter an MLS or vendor still offering RETS credentials, treat it as a legacy path and architect around the modern standard.

Do I need IDX approval to display MLS listings on my website?

Yes. IDX is the policy framework that grants the right to display MLS listings online. Before a developer can set up a RESO Web API feed, the broker or agent must have a signed IDX agreement with their MLS. The technical feed is issued under the terms of that agreement. No agreement, no feed.

What is the difference between IDX and MLS?

The MLS is the regional database and broker cooperative, where listings are entered and managed. IDX is the policy framework that governs who can display those listings on external websites. MLS is the data source. IDX is the permission to use it.

Is the RESO Web API free?

Access to the RESO Web API requires both IDX approval from your MLS (a policy step) and credentials from the MLS’s vendor platform (a technical step). Some vendors charge a monthly fee for developer access. CRMLS, for example, charges $85/month for a Trestle data feed. The RESO specification itself is an open standard, but production data access is subject to your MLS’s and vendor’s licensing terms.

Can WordPress display real MLS listings?

Yes. Obtain IDX approval, get RESO Web API credentials from your MLS’s vendor, and use an import plugin (such as MLSImport) to pull listings into WordPress as Custom Post Type records. A property-focused WordPress theme like WPResidence then renders those records as property pages, search results, and map views.

Which vendor should a developer choose: Bridge, Trestle, Spark, or Paragon?

You don’t choose the vendor. Your MLS does. Each MLS is contracted with one vendor platform that manages its data feed. Once you have IDX approval, ask your MLS which vendor they use, then register with that vendor. Multi-MLS aggregators (like SimplyRETS or MLSImport) support multiple vendor backends through one normalized API.

Four terms, four layers. The MLS is the database. IDX is the rulebook to access it. RETS was the old plumbing. The RESO Web API is the modern standard. The mental model is simple, but the messy reality (vendor layers, uneven adoption, local IDX rules that vary by market) is exactly why the simple model is worth keeping in your head when someone in the room starts using the wrong word.

If you’re a realtor, ask your MLS about their RESO Web API endpoint and what IDX participation requires for your website. If you’re a developer, start with your MLS vendor’s RESO Web API documentation and never architect a new integration around RETS. The 25-year RETS run is over. The next 25 years are JSON, OAuth, and the RESO Data Dictionary; the sooner your stack reflects that, the less rework you’ll do when your vendor’s last RETS endpoint goes dark.

FAQ

Is IDX a feed or a technical integration a developer implements?

No. IDX (Internet Data Exchange) is a legal-policy framework under NAR Policy Statement 7.58 and your local MLS rules. It defines who may display MLS listings online and what display requirements apply.

What developers implement is the data transport that sits under that permission: historically RETS, and now primarily the RESO Web API. When someone says “set up an IDX feed,” they usually mean “get IDX approval and then connect to the MLS data via RETS or (preferably) the RESO Web API using the credentials issued under that IDX agreement.”

What should I ask my MLS or vendor if they still offer RETS?

Ask what their RESO Web API endpoint is and what their RETS retirement timeline looks like. RETS was deprecated by RESO in 2018 and is no longer supported by RESO, and the industry retirement accelerated through 2024 with major vendor shutoffs reported.

If RETS credentials are still available in your market (often encountered on some Paragon-platform MLSs), treat it as a legacy path. For new builds in 2025-2026, architect around the RESO Web API (REST/JSON + OAuth2) rather than investing in session-based XML/DMQL2 plumbing that may be turned off.

How do developers actually get RESO Web API credentials if they rarely contact the MLS directly?

In most cases, you get IDX approval from the MLS first, and then the MLS points you to its vendor platform that manages the feed. That vendor (commonly Bridge, Trestle, Spark, or Paragon) issues the API endpoint and OAuth2 client credentials.

The RESO Web API is the standard, but the vendor is the access layer that authenticates against the MLS and exposes the data via standardized endpoints. Practically, you should confirm which vendor your MLS uses and follow that vendor’s documentation for registration, sandbox/sample access (if offered), and production credentials.

How can a WordPress site show real MLS listings with WPResidence?

The typical chain is: MLS database (source) -> broker signs the MLS IDX agreement (permission) -> the MLS vendor issues RESO Web API OAuth2 credentials (access) -> an import/sync layer pulls listings (often incrementally using ModificationTimestamp) and writes them into WordPress as Custom Post Type records -> WPResidence renders those records using its built-in property schema, search UI, maps, and templates.

WPResidence does not bundle an MLS feed by itself; it is designed to work with an import layer that maps RESO Data Dictionary fields (for example, ListPrice to the _price meta key) into the theme’s expected property meta structure. This CPT-based approach also keeps listings fully usable by the theme features, unlike many widget/iframe IDX solutions where listings live outside WordPress.

What is the practical difference between the RESO Data Dictionary and the RESO Web API?

They solve different parts of the interoperability problem. The RESO Data Dictionary is the shared field-name and data-type contract (for example, standardizing fields like ListingKey, StandardStatus, ListPrice, and ModificationTimestamp so the same concepts mean the same thing across MLS systems).

The RESO Web API is the transport specification that delivers that standardized data over a REST/JSON API built on OData v4, secured with OAuth2. In practice, the dictionary is what makes cross-MLS field mapping and consistent queries possible, and the Web API is the modern mechanism your application uses to request and receive the data.