Sign in to RPR
There’s certainly been a lot of buzz about the launch of RPR™, but even in advance of that, we’re preparing a public beta of service that will allow MLS organizations to programmatically access much of the rich public records content that RPR uses.
The RPR Public Records Application Programming Interface, or API, is for MLS organizations only, and provides a way for MLS Web applications to “talk” to RPR— requesting data that can then be analyzed and formatted for presentation on your MLS system. This is all done automatically, behind the scenes and transparent to your subscribers. Here are two excellent examples: pulling tax records to auto-populate a listing, or pulling comparable properties for display along side a listing. There are many possibilities! Best of all, you don’t need any problematic data feeds. You simply need development personnel skilled in the implementation of XML web services.
We want your feedback!
One of the challenges with producing a robust and stable API is that it is difficult to know how the entire user base will implement the functionality or the data it returns. Since we are releasing this API as a public beta even before the RPR Web site launches, we focused on a few of the essentials that resulted from talks with several initial MLS organizations:
- Provide data for the auto-population of listing input screens.
- Provide comparable properties for use on MLS property detail pages.
- Provide enough data to generate a property details page.
- Provide links back to MLS-branded pages on RPR for full property details, neighborhood demographics, charting, maps and all the other interactive functionality on RPR.
This API should be out the door sometime in February. We have additional functionality in the pipeline, which we will be deploying over time to support features of the RPR Web site as they are tested and released to NAR’s members.
With that said, we are interested in hearing your wants and needs for our upcoming releases. If you represent an MLS organization, please send your suggestions to us at and we’ll consider them for our API product pipeline.
You’re in luck! There’s already a vendor-community supported open standard for moving real estate data – RETS. By using an open standard one creates programming efficiencies while facilitating choice and competition – versus the use of a unique or proprietary API.
The work for public records has already been done: the vendor community worked long and hard to create the Public Record and Property payloads for RETS 2.0.
Please get involved in RETS and join the community!
Thanks Matt, we love standards!
We had some issues getting access to the RETS XSD files, but after contacting RETS.org we were able to get the Public Records payload XSD (it’s at http://www.rets.org/xsd/PublicRecords/2007-08/PublicRecords.xsd ). It’s a good start, but the schema hasn’t been adopted and there were numerous sections marked TODO.
We are interested in playing a part in the future development of this standard, and hope to circle back with a RETS-compliant public records API once the proposed schema matures and is adopted.
We’re also going to look into how well RETS 1.7 can support what we want to do with public records.
Brett,
I think I speak on behalf of the RETS community in general when I say we’d love to have your contributions. One of the major goals for 2010 for the RESO BoD is to finally get published a RETS Roadmap and Strategic Plan. A small group has been working on this for a long, long time. It seems as though as soon as we get something close to ready to publish a huge game changer pops up (like the NAR RETS MLS Policy 2 years ago). Now would be a great time for someone from your group to talk to us, perhaps we can try to include your goals with ours like we’re trying to do with Data Standarization with groups like the Cove Group.
Here’s to hoping we can all work together for increased efficiency in data transfer in and out of the MLS, into other amazing products popping up in our industry.
And here’s to hoping RPR doesn’t mean another game changer for RETS. We’ve made progress on our future goals as a community, I sure home the community effort doesn’t die.
Brett,
I appreciate your response. But it reminds me of the quote “All that is needed for evil to triumph is for good men (and women) to do nothing”. Circling back when the standard matures (ie when the todos are done). Will only ensure that RPR will not endorse the standard because they didn’t contribute and thus their API is incompatible.
Please reconsider participating early and often.
David
Brett – I’m glad you like standards and have an interest in working within the RETS framework. To echo David’s sentiment, the schema will mature and be adopted when you, as a member of the community, need and want it to be. I know you’re on a quick timeline – I suggest engaging the appropriate work-groups ASAP to ensure your needs are met in a timely fashion.
Hope to see you at the next RETS meeting!
I hate to do this to my boyz and all but…I must disagree. I think they can’t engage appropriate work-groups. I think Brett should talk to Paul Stusiak http://www.twitter.com/psftc and start a dialog. Paul can tell Brett what RETS needs in order to adopt what RPR needs. Brett goes back and does the leg work, returns to Paul and they both take the Schema Workgroup. Quicker, more efficient.
Kristen – it doesn’t seem that we’re disagreeing about taking it to the work group – you’re just suggesting he get help from Paul in going to the Schema Workgroup – which is a fine idea!
Thanks everyone! I’ve already been in touch with Paul about getting to the XSD files, and I’ll happily reach out again to see how we can help. Thanks for the advice!
This is a great resource. Will we be able to show how land and commercial brokers can use this? It will be a great recruiting tool if we can do a commercial geared demo as well.
My suggestion would be to create both a RETS web service and a RESTful web service both laid over the common data set. The MLS specific vendors you’re working with will probably prefer to consumer the RETS service, while any newer clients will probably prefer the RESTful API. A SOAP web service is no longer necessary and is increasingly being phased out by many providers.
It should not be much more work to support both styles – you can probably leverage some of the excellent open source RETS tools provided by NAR’s CRT group to quickly wire up and expose your SQL views via RETS. Then most language tools these days make it trivial to wire up RESTful API’s to those same views. Third-parties can then consume whichever flavor they wish, and the underlying data and business logic comes from the exact same place.
I think that this api should be open to broker software. It seems unfair to give mls software vendors such an advantage that seems to be locked out for software companies that develop real estate office management systems and agent productivity tools, like cma tools.
What is the deal with not having an api. Onboardinformatics has what we should be doing for ourselves, and theirs is a slim $795/mo for an agent. http://www.vendoralley.com/2011/08/18/dale-ross-ceo-of-rpr-doesnt-like-competition/
I am not sure if it is competition or obstanance? Thanks again, leadership! You Rock!