Skip to main content
The endpoint for the person enrichment api is 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 be 200, 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 a v5 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 a 200 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 a 200 HTTP response code. If we do not find a match we will return a 404 HTTP response code. Abridged Response Example (full example here):
This degree of confidence is represented by the 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 between 1 - 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

Email Hash

note you can use md5 or sha256 hashes

Email 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 the locality, 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 a 200. 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 different min_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 email
cURL
Response must contain a linkedin url
cURL
Response must contain experience and a current professional email
cURL
Response must contain experience or emails
cURL
Response must contain education and (emails or phone_numbers)
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