What is the RPR API?

The RPR Application Programming Interface (API) allows your MLS website to programmatically include public records data from RPR right on its own pages. Pre-populating listing input screens with public records data or displaying public records data and mortgage information alongside your listings are two of the ways it can be used.

Who can use the RPR API?

Only MLS organizations are allowed access to the API. It is not available for brokers or agents.

How can the RPR API be used?

• Pre-populating listing input screens.
• Generating comparable properties.
• Generating a more in-depth property details page.
• Providing links back to RPR pages for more data and interactivity. These pages can be co-branded.  See Deep Linking for details.

Additional functionality will be delivered based on market needs; send suggestions to APISupport@narrpr.com.

 

What methods are in the RPR API?

• GetProperties, for returning multiple property summary records (search results).
• GetPropertyDetails, for returning details about a subject property along with comparables if desired.

 

How does the RPR API work?

Your website makes a SOAP (Simple Object Access Protocol) web service call to one of the methods of the RPR API, specifying the appropriate username, password and query parameters. The API then looks up that data and returns it to you in the form of XML. Your website then transforms that XML into HTML for display on your website.

What geographical area does the RPR API cover?

The API has nationwide coverage with more than 130 million property records, but coverage and detail level of the various data types varies by location. Please see your RPR account representative for coverage information for your area.

What is included in the API?

The following data types are generally available nationwide, but coverage and detail level varies by location:

• Public Records (assessment data)
• Deed
• SAM (stand-alone mortgage records)

Future development will include links back to the rich data and interactivity of your own co-branded version of RPR (for those members with RPR logins).

 

What is not included in the API?

The following data are not included in the API for licensing reasons:

• Estimated Values (AVMs or RVMs)
• Listings data
• Neighborhood demographics
• Crime data
• Weather data
• Notice of Default (NOD) data
• School Information
• Data feeds; an API is meant for interactive querying, not the bulk delivery of data.

 

What is needed to implement the RPR API?

The RPR API is simple, but you need an application platform that can integrate SOAP-based XML web services as well as application programmers experienced in working with web services.

Can I see some sample XML responses?

Sample XML responses for each method are available here. The XML responses may change as we receive feedback from end users. Sample responses will be published in the API information site we are building for a future release.

Is there a test interface to use?

There is no simple http test interface to use, but your development platform should include a tool to access these web services. For Visual Studio users, the WCF Test Client is available within the Visual Studio program files directory.

How do I get an API account?

Personnel authorized to enter into agreements on behalf of the MLS can request an API account at http://blog.narrpr.com/tax-api. If access is approved, you should get your API account within three business days.

If you represent a technology vendor and have multiple clients interested in the API, each client must individually accept our terms of use and receive their individual API account.  The appropriate credentials must then be used by your system to request RPR data on behalf of the MLS.  Account sharing, for any purpose whatsoever, is strictly forbidden.

 

How is the API supported?

RPR maintains the operation of the API and the data therein, but we cannot provide support to developers trying to integrate the API. Please ensure that your developers are experienced with SOAP-based XML web services, and ideally that they also have the ability to integrate an API defensively so API problems do not cause errors on your website if the RPR API has a hiccup.

 

What is the API release process?

Changes in the RPR API can require changes in the codebase of your own application.  This means that the release process for the API is much more involved, for both parties.  Generally, the process is as follows:

1. RPR will attempt to provide the MLS community with release notes regarding the changes to the API just prior to the release to QA.
2. API users will be requested to test their applications against the API in our QA environment.
   1. If the MLS API integration functions as-is, no deployment challenges are involved.
   2. If the MLS API integration does not function as expected, code changes may be required on one side or another.  It is therefore critical that testing be performed as early in the QA release cycle as possible (often we only have 2-3 days to identify and address bugs).  Additionally, once functionality is restored it will be necessary for the MLS to coordinate their website patch with RPR's release date.  Defensive coding should be added where possible, to reduce the probability of failures in the future.
3. RPR will notify users that a new production release has been deployed.
4. API users should re-test their applications in their production environment once the RPR API release has been deployed.

 

How reliable is the RPR API?

The API is designed to be a highly available enterprise-class platform. However, it is always wise to integrate the API into your website in such a way that an API outage or error does not adversely impact your website. Your programmers should therefore implement defensive coding practices to minimize these impacts.  It is also recommended that you employ a configuration switch that allows you to turn API integration on and off on-the-fly.

How can I offer feedback on the API?

This is a very early version of the API, and we hope to build out functionality over time as it is requested by the user community. Please send your ideas/comments/feedback to APISupport@narrpr.com.

 

Should I use the API, or request a data feed?

Currently, the only method to get data from RPR is via the API. This is by far our preferred delivery method for several reasons:

• It's interactive, so you only get back the data you request.
• It's fast and reliable.
• There are no disk storage requirements (our public records data spans many, many terabytes).
• There are no complicated transfer mechanisms for large data files to build and maintain.
• All the heavy lifting is done by RPR. There's no need to optimize database calls, etc.
• The API is always in sync with the main RPR website.