RPR seems to be getting traction, at least among more of our clients. But many MLSs coming to us to have the RPR contract reviewed come with a big misconception. I usually first ask them what their business objectives for the relationship are, and almost every one has said, “We want to reduce our costs by replacing our public records provider with data from RPR.”
We seem always to have to explain two things:
- Your MLS does not have to provide MLS data to RPR in order to get public records from RPR. (Though I don’t know personally of MLSs using the API who are not licensing data to RPR, I take RPR at its word that an MLS does not need to license data to RPR to use the API.)
- The RPR agreement for its public record API provides none of the assurances you would normally expect from a public records provider. For example, RPR can terminate the agreement and stop providing public records to your MLS without notice; RPR does not warrant non-infringement; your MLS agrees to indemnify RPR, but not the other way round; etc. (See the agreement for the API at: http://blog.narrpr.com/tax-api .)
I’m not trying to knock the RPR API agreement; if I were giving away access to valuable PR data, I’d offer it under a pretty one-sided contract too. If your MLS currently does not have public records, or if you are not concerned by the possibility of an interruption in your public records access, the RPR API might be a good option. (We’d still caution you about some of the provisions in that API agreement, but the bargain might be worth assuming some risks.)
But if your MLS currently has a public records agreement and wants a source of public records on which it can rely, the RPR API is not a good substitute for a contract with CoreLogic, LPS, iMapp, or one of the other providers out there.