Verify Realtor Pricing


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.


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


 The pricing for our tiers is based on the number of monthly web service calls:

Web Service PlanMaximum Monthly SearchesAnnual FeeActivation 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 


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.


The VerifyRealtor.COM Licensee Verification Web Service requires a subscription in order to use. To set up a user account, contact VerifyRealtor at

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.


The VerifyRealtor.COM Licensee Verification Web Service uses the W3C XML SOAP protocol (v1.1) for exchanging information ( 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:


Figure 1: A web service request.

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   

Table 1: Properties of the Request Variable                               

How Searches Are Performed 

In order to get the best and most reliable results from the Licensee Verification Web Service, it is important to understand how the web service searches the database. Understanding the search routine will help you to know what data to provide, what is most important and what is least important in getting meaningful results


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 

                                       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

Due to the large number of records in the Licensee Verification Database, it takes a lot of processing power to search it. In order to reduce the time it takes to search the database, searches are stored in memory whenever possible, to reduce the number and size of database queries. As a result, the order of the search becomes important.

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:

Figure 2: The web service response

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:

Table 3: Properties of the Result Variable


Error Messages (Faults)


If the web service encounters an error, a return value called a “fault” is generated in the response. Theproperty ofcontains an array of Fault objects. The Fault data type is a structure with three properties:

Table 4: Properties of the Fault Variable

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.

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 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:


 XML:

 CSV: 

    These resources include the following information for each jurisdiction:

These resources include the following information for each jurisdiction:

  jurisdiction: part 2