IDX vs VOW vs RESO Web API: which MLS data access do you need?

The short answer

Most agents and brokerages need IDX, delivered by an IDX provider. That covers public property search, listing pages and lead capture on your website.

VOW and broker back office feeds are different licenses for different jobs: registered-user search and internal brokerage tools. The RESO Web API is not a license at all. It is the technical pipe that carries whichever data you are licensed to receive.

If you are new to the topic, start with What is IDX? and come back here when you are weighing your options.

Policy vs. transport: the distinction that clears up confusion

Most mix-ups come from treating two different things as one.

• Policies and licenses answer what you may do with MLS data. IDX, VOW and the brokerage back office feed are all defined in NAR’s Handbook on Multiple Listing Policy, and each MLS turns them into its own rules and agreements.
• Transport standards answer how the data gets from the MLS to software. RETS was the older standard. The RESO Web API is the current one.

A useful way to think about it: the license is the permission slip, and the Web API is the delivery truck. You need the permission slip no matter which truck you use. RESO’s own Web API page makes the same point in practical terms: recipients agree to an MLS’s data use and licensing policies first, then get credentials from that MLS’s software provider or technical staff.

IDX: public display on your website

IDX lets MLS participants display each other’s listings to the public. Under NAR policy, displays must identify your brokerage, credit the listing firm and its contact details, leave out confidential fields and refresh at least every 12 hours. Individual MLSs, such as CVR MLS, write these requirements into their own rules and often add more.

Key traits:

• Audience: anyone who visits your site, with no registration required by the policy itself.
• Who holds the right: the MLS participant. Agents can display IDX where the MLS allows it and their broker consents.
• Data: public-facing fields only. What statuses are included, such as sold or expired listings, varies by MLS.

IDX is the right fit for nearly every agent and brokerage website.

VOW: search for registered clients

A Virtual Office Website is defined in NAR’s VOW policy as a participant’s website, or a feature of one, where consumers can search MLS data after first establishing a broker-consumer relationship as defined by state law. The idea is to let a brokerage deliver services online that it would otherwise deliver in person.

NAR’s VOW policy sets requirements that IDX does not have:

• Registration. Each user provides a name and a valid email address, creates a unique username and password, and affirmatively agrees to terms of use. The broker emails the user to confirm that agreement.
• Data depth. A VOW can draw on the MLS’s non-confidential listing data. Sold prices may be treated as confidential in states where they are not public record.
• Refresh. Data must be refreshed at least every three days.
• Result limits. An MLS may cap how many listings a user can retrieve per search, but not below 500 listings or 50% of the MLS, whichever is less.
• Seller opt-outs. Listings or addresses that sellers have kept off the internet cannot appear.

MIBOR’s data licensing page notes that an agent may operate a VOW with their broker’s consent, under the broker’s oversight. VOWs are less common than IDX sites because the registration flow, agreements and data handling take more work to build and maintain.

Broker back office: internal tools, not public display

NAR policy also requires MLSs to provide participants with a brokerage back office (BBO) feed. The handbook describes it as covering all listing and roster information in the MLS, minus MLS-only fields and content the MLS lacks the license to share.

Permitted uses include brokerage management systems, CRM and transaction management tools, agent productivity and ranking reports, and market statistics. Under NAR policy, participants cannot opt their listings out of BBO use.

MLSs package this in different ways:

• MIBOR offers four license types through MLS Grid: IDX, VOW, Back Office and Broker Only. The Broker Only feed covers just the firm’s own listings for internal use.
• Canopy MLS describes its back office feed as intended for internal functions without public display, yet it also lists agent production analytics, comparative market analysis, market analytics, and IDX and VOW uses among the permitted purposes.

Read your MLS’s agreement closely. What one MLS permits under a back office license may need a separate license elsewhere.

RETS and the RESO Web API: how the data moves

For years, MLS data moved over RETS, the Real Estate Transaction Standard. In June 2017, RESO announced at its Spring Summit that the RETS workgroup would be sunset after the RETS 1.9 release. RESO now describes RETS as deprecated and no longer supported.

Its replacement is the RESO Web API, which RESO calls “the modern way to transport data in the real estate industry.” It uses common web technology:

• A RESTful design built on the OData V4 standard
• OAuth for authentication and authorization
• The RESO Data Dictionary, which standardizes field names and values, with MLSs certifying Data Dictionary compliance on the Web API

A guest post on RESO’s blog explains the practical difference. RETS typically meant copying a database of listings onto the vendor’s servers and updating it incrementally. The Web API lets applications query the MLS directly.

NAR policy has required MLSs owned by REALTOR associations to implement the Data Dictionary by January 1, 2016, and the Web API by June 30, 2016. It also requires that Web API access offer at least as much data as older methods like RETS or FTP, and that MLSs adopt new RESO releases within a year of ratification.

Side-by-side comparison

Who typically uses each

• Solo agents and teams use IDX through a provider. They rarely touch the Web API directly. See IDX websites for agents.
• Brokerages use IDX for the public site and often license a back office feed for CRM, recruiting reports or market statistics. See IDX for brokerages.
• Web designers and agencies usually build on an IDX provider’s tools rather than raw feeds, which keeps MLS approval and compliance with the provider. See our agency program.
• Software developers building custom products work with the RESO Web API and must still hold the right license for each MLS. Platforms like MLS Grid handle licensing for many MLSs; Canopy MLS says MLS Grid is RESO compliant from the Web API to the Data Dictionary. Some IDX providers also offer their own APIs; IDX Broker, for example, has an API and developer partner program for custom IDX-powered sites.

When IDX is enough, and when you need a custom build

IDX through a provider is usually enough when:

• You want public search, listing pages, saved searches and lead capture.
• You want the provider to handle the feed, refresh timing and display requirements.
• You work in one MLS, or in several the provider already supports.

A custom build is worth considering when:

• You need a true VOW with registration, client agreements and deeper data.
• You want internal dashboards or analytics, which call for a back office license, not IDX.
• You need a search experience or data model no provider template supports.
• You have developers who can maintain a Web API integration and keep up with each MLS’s rule changes.

A custom build adds cost and responsibility. Your team, not a provider, becomes accountable for compliance with every MLS you pull from. Rules differ by market, so check each one before you commit; our MLS directory is a starting point.

For most of the agents and brokers we work with, a well-built WordPress site on IDX Broker covers the need without a custom data project. See it for yourself on our live IDX demos, then read Get Started to see how sign-up and MLS approval work.

Frequently asked questions