Getting Started with MLS and RETS Programming

Just recently, our company developed and launched RevBroker, a real estate product that serves as a tool for brokerages to provide listings, agent pages, and CRM features. We’ve built custom sites for real estate firms before, but to create RevBroker I was tasked with taking our current implementation and turning it into a viable product that multiple brokerages could use. Here, I share the tips I learned on my confusing journey to handle MLS data and RETS programming.

Getting Started with RETS programming

As I got started on this project, I thought that the hard work of importing data, maps, and search was actually taken care of through the local real estate exchange. I believed that all I needed to do is change credentials and add the extra pages requested. WRONG. This was my first time dealing with any sort of MLS data and it hit me like a ton of bricks.

The main problem is that there just is not a whole lot of information out there on how to start this process. Almost everything I found was a vendor trying to sell me their system or services for building out a site using MLS data and almost nothing on here is where and how to start and some steps to take.

What is RETS and MLS?

MLS stands for Multiple Listing Service. It is a suite of services that facilitates the gathering and releasing of real estate listing information from broker to broker, and from broker to the public. The challenge in handling this data is that there are over 1400 MLS organizations around the country, and there is no universal data format for them. Essentially, this means there are 1400 different databases for the same thing that potentially have different formats. This is where RETS comes in.

RETS stands for Real Estate Transaction Standard. RETS is a framework developed by the National Association of Realtors in an attempt to make the exchange of data easier and more standardized. Before RETS, FTP protocol was used to get MLS data. The scale of these databases is huge, and FTP did not allow for the querying of data.

Prior to RETS, this meant that in order to update listings, the entire database had to be transferred and compared to a local copy for updating. This was not the speediest of processes to have to run everyday –  much less multiple times in a day. RETS allows querying and only pulling the new or updated data into a local db.

Seems great: make something non-uniform into an industry-wide standard. Well, the issue that remains is that there is still no true standardization of the different datasets. Each MLS dataset can, and many do, have very different approaches to naming fields in their datasets.

Plan Your MLS Project

So now, we at least sort of know what we’re dealing with and where some pain points are going to come in. If you can pinpoint that before estimating your project hours and getting started, then you’re already ahead of the game.

The starting point is really determining the rules for the MLS system that you want to access. Like I said earlier, all of the MLS systems are different. Not only do they differ in how the data is presented but also in how they provide access to that data and who gets access to it as well. So, if you’re building a site with a broker client in mind already, you’ll be connecting to their local MLS and following the protocol set by that Realtor organization. But, if you’re looking to build a product as a vendor without a client in mind, you’re going to need to select an MLS area and set up your vendor access.

For instance, in Revelry’s first implementation we were able to easily gain access to our local MLS listings and hook up a client to import them. But with the most recent implementation, not so much. After several hours of scouring a particular local MLS site and trying to find the steps for access, I realized that we needed to become a vendor for that specific area and prove that we were building the site for a particular client. This is not a difficult process, but it adds time to the project plan. Learning this lesson added a week to our timeline.

Other Options for MLS Data Access

You will also read a lot about IDX (Internet Data Exchange), a property search site for pulling MLS data. IDX can be a great solution; they take MLS data and do the translating and mapping for you. It depends on what your needs are.

  • IDX offers a few impressive features. If you’re building on WordPress, there is a plugin that seamlessly connects with IDX.  IDX also offers a widget that you can embed in your site for full MLS search functionality, an API to connect to and pull in your client’s MLS listings, and access to hundreds of MLS systems.
  • But IDX actually didn’t work for our needs in this case. We weren’t building on a WordPress platform, and we weren’t happy with their non-WordPress options. The API will only allow you to pull your client’s listings, not the listings for the entire local MLS. And, when choosing to embed the IDX widget, you lose all SEO data which we needed.

If IDX works for your implementation, I would recommend it with the caution to verify that the MLS systems accessed include your client’s required areas.

Building with Direct RETS Access

Here at Revelry we opted for RETS programming via direct access and decided to build out our own importer to pull and search for listings. The local MLS also provided a few options including a widget, but we still used the direct feed for the same reason of controlling SEO mentioned above. This meant using the local matrix system and doing all of the dirty work ourselves.

If you’re going the custom route and using Ruby, I would recommend the Rets gem from Estately. It was incredibly helpful in our process.  Even with the Rets gem this proved to be a somewhat daunting – or at least very tedious – task.

The Rets gem allowed us to easily query the MLS system and pull data over, but once it’s pulled via the API you’ve got to map it to the data fields you’ve created. This can get messy. MLS fields are not defined in the same way from system to system. For example, one MLS may send you an address in an all-inclusive address field while another may send Street Number, Street Name, Street Abbreviation. This has to be accounted for when you have one database map and multiple MLS imports coming into it.

We handled this via a field mappings file we built to include in our importer. It’s a tedious process and my only advice here is to grab some coffee and some patience, and roll up your sleeves to get to work. This is why IDX is a great solution if it works for you; all of this work is done within IDX.

It would be great if sometime in the near future, everyone can agree on one standard data format for MLS. Helping independent brokers cut through this level of difficulty to provide custom websites and home search engines is why we built RevBroker, so the frustration was worth it.

If you’re building a real estate site, I hope I’ve provided you with enough of a head start so you don’t have to crawl through the weeds as long as I did. These tips should help you better estimate the level of effort for your implementation.
Have any of you had some experience dealing with MLS? Please share your stories in the comments! Just starting out and have a question about something not covered here, please reach out and I would be happy to provide some guidance.

The Revelry team believes in being excellent to each other and shipping great software.

We live our core values every day.

On the Revelry blog, our team shares tips, tricks, and strategy for building innovative products.
Check out our posts on Product, Team News, and Development.

Connect with us on Facebook or Follow us on Twitter!