Verify Realtor Pricing
LICENSEE VERIFICATION WEB SERVICE (VRWS)
Verify Realtor® maintains a database of over 3 million real estate licensees. We receive licensee data directly from participating jurisdictions, most updated daily. With the Verify Realtor® Licensee Verification Web Service, you can fully automate searches of our database and take the work out of licensee verification.
Documentation
We currently offer a SOAP API into our database for a fee. Taking advantage of the API allows you to fully automate licensee searches using a script or program you design. See the documentation for more information.
Verify Realtor® VRWS Documentation
Pricing
The pricing for our tiers is based on the number of monthly web service calls:
| Web Service Plan | Maximum Monthly Searches | Annual Fee | Activation Fee (Non-Refundable) |
|---|---|---|---|
| Verify Realtor® 500 Plan | 500 | $1,350 | $150 |
| Verify Realtor® 1K Plan | 1,000 | $1,700 | $150 |
| Verify Realtor® 10K Plan | 10,000 | $3,500 | $150 |
| Verify Realtor® 25K Plan | 25,000 | $4,750 | $250 |
| Verify Realtor® 100K Plan | 100,000 | $6,500 | $250 |
| Verify Realtor® Unlimited Plan | Unlimited | $7,500 | $350 |
Ready to try?
If you'd like to try out the service, please contact us or call 212- 265-2525 and we'll set you up with a testing account to use to develop your application. The testing account is completely free, and it performs exactly like a live account, but uses a small, random subset of the live data as well as a few seed records to aid in testing.
VerifyRealtor.COM Licensee Verification Web Service Documentation
Introduction
The VerifyRealtor.COM Licensee Verification Web Service allows clients to obtain real estate licensee information in an automated fashion via a single HTTP request. By supplying the practitioner’s jurisdiction, license number, last name and first name in an XML SOAP request, the service returns matching records with a confidence factor indicating the degree to which the result matched the parameters.
Subscription
The VerifyRealtor.COM Licensee Verification Web Service requires a subscription in order to use. To set up a user account, contact VerifyRealtor at support@VerifyRealtor.com
Once you set up a user account, you will be given a unique username and password to use in web service requests. You must provide a valid username and password combination in order to use the service.
Any search that completes successfully and does not result in an error is logged to the database and will be logged to your user account and count against your monthly quota.
Interface
The VerifyRealtor.COM Licensee Verification Web Service uses the W3C XML SOAP protocol (v1.1) for exchanging information (http://www.w3.org/TR/SOAP). Most server-side scripting languages have native support for SOAP (ASP.NET, JAVA, PHP, ColdFusion, etc…). Specific instructions for using native server-side language SOAP libraries are beyond the scope of this documentation; we will provide examples of the XML formatting required for the request and returned in the response, which can be sent over HTTPS (SSL) to use the web service. Due to the sensitive nature of the data being transferred, the web service requires SSL encryption on the standard SSL port 443
PLEASE CALL 212-265-2525 to accesse the web service
Formatting the Request
The web service expects to receive an XML SOAP envelope over HTTPS in the following format:
The tag tells the server which method to execute (in this case, the “verify” method of the web service). Each of the tags within the tag are the arguments passed to the verify method, which include the search parameters. All arguments are required in the request (as in any SOAP request), but some of them can be null.
Table 1: Properties of the Request Variable
How Searches Are Performed
Search Parameters
Searches can only be performed on data that you provide. If you omit any of the search parameters, the likelihood of erroneous results increases. It is to your advantage to provide all the search parameters.
Each search carries with it a “weighting” factor. Confidence values in the result set are calculated using the weights of each search.
Here is the search algorithm:
If the License Number parameter is provided
A search is executed for an exact match of the license number. Weight: 12
If no exact matches are found AND the License Number is 3 or more characters in length
A search is executed for a wildcard match of the license number. Weight: 6
If the First Name and Last Name are provided o A search is executed for an exact match of the full name. Weight: 5 o If no exact matches are found
A search is executed for an exact match of the last name AND a wildcard match of the first name. Weight: 3
If only the Last Name is provided OR there were no First/Last Name matches
A search is executed for an exact match of the last name. Weight: 1
The search algorithm can match results at two different levels. An “exact” match is just as it sounds; all characters in the field matched exactly to the parameter provided. If no exact matches are found, the algorithm may execute a second search for a “wildcard” match. A wildcard match indicates that a field in the database contains the value in the search parameter but is not an exact match.
For example, suppose you submit a license number search parameter of “32668,” but the jurisdiction actually pads the license number with zeroes, like “000032668.” While an exact match would not be returned, a wildcard match would, because the license number contains the character sequence you provided.
After the searches are complete, the results of each search are assigned a “score” equal to the weight of the search. Scores accumulate on results as multiple searches are done, and the higher the score, the better the confidence that the result is a match to the person you are looking for.
As you can determine from the algorithm, the highest possible score for a match is 17. This would indicate that the license number was an exact match (12) and the full name was an exact match (5). Confidence values for results are determined by normalizing the score to a 0-100 scale (percentage scale).
Confidence = (score * 100) / 17
Here is a breakdown of all possible confidence values, and what they indicate:
Table 2: Possible Confidence Values
Note that it is to your advantage to provide all the search parameters when searching. Results from searches which do not include a license number can have a maximum confidence of 29%, and results from license-number-only searches have a 71% maximum confidence value.
Searching Within Results
It’s important to understand that license numbers take precedence over names when searching. If you supply a license number in the search parameters, the license number search will be performed first. If the search algorithm finds one or more matches using that number, the subsequent name-based searches only take into consideration the results from the license number search. The full database is not searched again.
Reading the Response
The response from the web service includes three distinct parts.
The request information that produced the response.
The results of the search.
Any faults that may have occurred.
Multiple results may be returned, as well as multiple faults.
The response is formatted as follows:
Looking over the example return value above, you can see that the tag is a container for the entire response set. The tag contains a copy of the parameters passed in the web service request. This particular search was for an individual named “John Doe” with a license number of “123456789” in the jurisdiction of “al” (Alabama). For security reasons, your password is not echoed in the request block.
The search returned no faults, and therefore the tag is empty. For more details on faults, see the next section.
The search returned one result in the tag. The tag contains an array of Result structures with the following variables:
Multiple faults may be present in the response.
In cases where the error is minor, the web service may be able to recover from the fault and still produce a usable result. These faults are called “Warnings.” A Warning indicates that something went wrong while processing the request, but the service was able to correct the problem and still produce results. Examples of events that produce Warnings include:
Providing a result Limit or confidenceLimit that is out of range.
In the case of Warnings, the service simply corrects the erroneous value to an acceptable value, and continues to perform the search. Searches that produce Warning faults will still return results, and therefore they are logged to the database, just like a normal search.
In other cases, the service may be unable to recover from a fault or unable to produce usable results. These faults are called “Exceptions.” An Exception indicates that a non-recoverable error occurred and the service could not continue executing. Examples of events that produce Exceptions include:
Providing an incorrect username/password combination in the request
Failing to provide required search parameters, like “jurisdiction” and “lastName”
Providing an incorrect jurisdiction abbreviation
If an Exception is produced, the search is not logged to the database, since no usable results can be produced.
Testing Phase
When a subscription is initially configured, the new account will be set up to use a database with test data. While using the test database, searches are not logged. After the subscriber is confident that his code is properly consuming the web service, he may request to be switched to the live database. At that time, all searches are logged and billable.
The testing database is comprised of a random 1% of the records from the live database. There are also several records of bogus data that can be used for assuring that the web service returns expected results.
Users can enter any of the above as is and get a 100% confidence match. One can also obtain different confidences by using certain data.
Searching for license number "12345" in AL gives two results with 35% confidence (a wildcard license number match).
Searching for license number "000012345" and last na
Searching for license number "9487" in AK gives two very different results with 35% confidence (wildcard license match).
Adding last name "jones" to the above increases the confidence slightly, but enough to exclude the other result.
Account Area
All subscribers have access to a secure account area on the VerifyRealtor.COM website.
This area can be accessed by visiting https://www.VerifyRealtor.com/accounts/ and logging in with the username and password used by the web service account. SSL is required.
Account holders will have access to terms, invoices, and details of the search history used by the web service client.
Jurisdiction Participation and License Format Information We’re constantly working with our jurisdictions to get the latest information as frequently as possible, but unfortunately, we still don’t have 100% participation. Some jurisdictions are unable to participate for legal reasons, and some are simply not VerifyRealtor members.
Additionally, jurisdictions which do participate have varying license number formats, and it can be difficult to get an exact match without knowing something about the format before conducting a search.
To help you perform better searches, we provide information about jurisdiction participation, update frequency and license number format in several formats which you can access and use in your client application. Endpoints and available formats:
JSON: https://www.VerifyRealtor.com/api/participants.cfm?format=json
XML: https://www.VerifyRealtor.com/api/participants.cfm?format=xml
