https://api.peopledatalabs.com/v5/person/enrich
Person Enrichment API Access and Billing
You can access the Enrichment API through our self-signup dashboard When a matching person is returned, the HTTP Response code will be200, and when no matching person is found or returned, the HTTP Response code will be a 404. We charge per match.
Usage
The person enrichment API provides a one-to-one match, providing up-to-date information on a unique individual.Requests
See Authentication and Requests to see possible ways to input requests. We recommend using a JSON object to capture input parameters and will do so in the examples below.Rate Limiting
Our default limit for free customers is 100/min. Our default limit for paying customers is 1000/min. In order to allow for more enrichments without putting too much strain on our system, you can use the v5/bulk endpoint to increase the number of enrichments per request, artificially increasing your rate limit up to 100x.Input Parameters
Data points on the queried person are added as key/value pairs to the query string of av5 request.
The following parameters can be used to specify information on the requested person. Adding more data points to a request increases the probability of a 200 response, and further, will increase the accuracy of the response’s Likelihood Score.
All query parameters listed below are optional.
Minimum Inputs
The minimum combination of data points a request must contain in order to have a possibility of returning a200 response are:
cURL
Response
When an API request is executed, the queried data points are preprocessed and built into a query, which is then executed against our api dataset. If the query yields 1 or more matching persons from the dataset, the person returned in the API response is the one who is most likely to be the same person as the person requested and it will return a200 HTTP response code. If we do not find a match we will return a 404 HTTP response code.
Abridged Response Example (full example here):
likelihood field in the API response. The likelihood field is an integer between 1 and 10 that represents how confident we are the person returned is the same as the person requested. You can read more details here. The minimum likelihood score a response must possess in order to return a 200 can be controlled in the api request using the min_likelihood param, described in the parameters section below.
Likelihood Score
What is it?
Every match that the API finds during the enrichment process is assigned a likelihood score, which is an integer between1 - 10 representing the confidence that the returned profile is the same as the profile requested. A score of 1 represents a very low confidence level, and 10 represents the highest degree of confidence. The likelihood score is logarithmic such that a response which returns a likelihood score of 2 will roughly have just a 10 to 30 percent chance of being the same person as the one requested.
As an example, requesting for “John Smith” in “New York” does not provide enough information to yield a result that we can confidently say is the exact John Smith that was requested (since there might be a lot of John Smiths in New York). However if an email, a phone, and a street_address were all attached and matched in our data, we can be highly confident we are correctly returning the intended John Smith.
How to use it (min_likelihood param)
You can use the min_likelihood parameter in your API request to specify a threshold likelihood score you want the response to meet or exceed. This parameter allows you to specify the tradeoff between precision and recall. In other words, using a high min_likelihood value will only return very strong matches, but at the risk of not returning any match at all if none can be found above the min_likelihood threshold. Alternatively, using a low min_likelihood value is more likely to give you a match, but at the cost of returning a potentially weaker match.
Some general rules of thumb for setting this parameter are as follows:
- For use cases which rely on a high degree of data accuracy, use a value of
≥6 for the min_likelihood value - Requests made with only a few less-specific data points, e.g. a name and location, generally return a response with a likelihood score
≤4 - Requests made with just an email or non-mobile phone generally return a score between 3 and 6
- Requests with a mobile phone or LinkedIn return a likelihood score
≥7
Examples
When using a URL, all query parameters should be separated by an ampersand&. When using code, all request parameters should be lists.
All examples are provided in cURL, JavaScript, Ruby and Python. If you aren’t comfortable operating in these languages, feel free to use this handy tool to convert from cURL to the language of your choice.
Linkedin URL
Email Hash
note you can use md5 or sha256 hashesEmail and Company
Name + Company + School
Name + Location + Twitter + Phone
Multiple Values for the Same Parameter
Most parameters can take multiple values. To do so, simply append the parameter with values as many times as needed. The only parameters that cannot exist multiple times are thelocality, region, country, and street_address parameters, since these are all linearly related and multiple inputs would make it impossible to match. To match on multiple locations use the location parameter.
Controlling What Counts As A Successful Response
These parameters can be used to describe the characteristics an API response must possess to return a200.
For more information on the
min_likelihood param, see the likelihood section, and for more information on the required param, see the required param section.
Controlling What the Response Looks Like
The following parameter can be used to control/specify certain things about the formatting of the person data in the API response.
More on the include_if_matched field
Check out the match object request for the following example queries:
name=sean thornelius&profile=linkedin.com/in/seanthorne
first_name=sean&last_name=thorne&company=people data labs&location=abu dhabi
min_likelihood
Setting a differentmin_likelihood value in the requests allows you to control the specificity of our matches. For use cases which rely on a high degree of data accuracy, only records with a likelihood of approximately 6 or above should be used. By default, match recall is kept very high, so a response which returns a likelihood score of 2 will roughly have just a 10 to 30 percent chance of being the same person as the one requested. Adding more data points to your requests will increase the probability of a 200 response returning a higher likelihood score.
Requests made with only a few data points, e.g. a name and location, will rarely return a 200 response with a likelihood score > 4, and requests made with just an email will rarely return a 200 response with a likelihood score > 6.
Required Parameter
The required parameter ensures that you only get charged for responses which have the data fields you’re interested in. You can use any top fields for required parameters except those you use as search parameters/input fields. If you include a field in both the request and the required parameters, the required parameter will not work. The value is formatted as a boolean statements.Examples
Response must contain an emailcURL
cURL
cURL
cURL
cURL
Valid Required Parameters
Any top-level fields may be specified in the required params. See example fields in the section below:Full Example Response
JSON
