Free plans, by default, do not have access to contact fields like emails, phone numbers, and street addresses and will instead appear as true if the value exists or false if it does not. To unlock the values, please upgrade to a Pro plan. Read more here: Plan types: Free vs Pro
For a simplified overview of our person fields, check out the Person Data Overview.
For more details about our person fields, including fill rates and which fields are included in the base vs premium field bundles, check out our Person Stats pages.
For a full data ingestion JSON schema, check out this page.
If you'd like access to premium fields or have questions about which fields are included in your specific field bundle(s), please speak to one of our data consultants.
Identifiers
first_name
Description
The person's first name.
Data Type
String
Field Details
The person's first name.
Example
"first_name": "sean"
full_name
Description
The person's full name.
Data Type
String
Field Details
The first and the last name fields appended with a space.
Example
"full_name": "sean thorne"
id
Description
A unique persistent identifier for the person.
Data Type
String
Field Details
The ID is a unique, persistent, and hashed value that represents a specific person.
As of v24, IDs have a max length of 64 characters, although in practice we expect IDs to be closer to 32 characters in length.
The mobile_phone field is generated from a highly confident source of mobile phones. We've hand-validated a sample of these and seen over 90% accuracy.
This field is generated by analyzing the all of a person's emails in the personal_emails list to identify the best available email.
Through testing, we’ve found that using the email identified in recommended_personal_email versus selecting a random email address from personal_emails resulted in ~37% higher deliverability.
The value for this field must use valid email address formatting. It is common and expected that work email domains may differ from the company's website for a number of reasons:
The company changed their website domain
The company has opted for a shorter email domain
The company has been merged into or was acquired by another company
These fields describe the company the person currently works at. These fields will match the corresponding values in our Company Schema and will use the same formatting and parsing logic.
job_company_12mo_employee_growth_rate
Description
The person’s current company’s percentage increase in total headcount over the past 12 months. Mapped from employee_growth_rate.12_month.
Growth rate is calculated as (current_employee_count / previous_employee_count) - 1.
An update is the time when the current employment information is modified in the record.
🚧
Limitations of Observed Data
This field reflects observed data. This means that this timestamp will reflect the date when updates were propagated into our data build from our data sources, and may contain some lag time compared to real-life events. For example, if User A changed their job on October 1, 2023, but did not update that publicly until December 1, 2023, our timestamp for job_last_changed will be December.
Example
"job_last_changed": "2023-12-01"
job_last_verified
Description
The timestamp that reflects when the top level job information was last validated by a data source.
An update is the time when the information in a record is validated through a data source. For more information how this timestamp is generated see: Experience & Location Updates
Example
"job_last_verified": "2024-01-05"
job_onet_broad_occupation
Description
The O*NET Broad Occupation associated with the person’s current job title.
Data Type
String
Example
"job_onet_broad_occupation": "Chief Executives"
job_onet_code
Description
The 8-digit O*NET code for the person’s current job title.
A more detailed job title classification than O*NET Specific Occupation.
Data Type
String
Field Details
A more detailed job title for records where the specific occupation within O*NET's standard hierarchy isn't granular enough to accurately describe the job title.
For example, the highest level of granularity in O*NET for C-suite positions is Chief Executives. With this field, we can specify the type of executive role.
Major Improvements Scheduled for v28.0 (October 2024)
In v28.0 (October 2024) we will be making significant improvements to our role and sub_role categorizations and changing the canonical values associated with these fields.
Major Improvements Scheduled for v28.0 (October 2024)
In v28.0 (October 2024) we will be making significant improvements to our role and sub_role categorizations and changing the canonical values associated with these fields.
If this field exists, birth_year will agree with it.
Example
"birth_date": "1990-12-02"
birth_year
Description
The year the person was born.
Data Type
Integer
Field Details
The approximated birth year associated with this person profile. If a profile has a birth_date, the birth_year field will match it.
Example
"birth_year": 1990
sex
🚧
gender was renamed to sex in v26.0
In v26.0 (April 2024) we renamed this field from gender to sex, in accordance with legislative changes defining aspects of gender as sensitive personal data (which PDL does not process or output).
PDL values high confidence data that is very likely to be associated with a person. The data in these fields have lower confidence than the data used in other fields.
possible_birth_dates
Description
Birthdays associated with this person that have a lower level of confidence.
We currently cover person social profiles on our Canonical Profile Networks. All profiles we've found for a person will be added to the profiles list.
Each social profile URL has one or more standard formats that we parse and turn into a standard PDL format for that social URL. We invalidate profiles that have non-valid person stubs (for example, linkedin.com/company), and we also have a blacklist of usernames that we know are invalid.
We do not validate if a URL is valid (that is, whether you can access it) because doing this at scale is considered a Direct Denial of Service (DDoS) attack and/or a form of crawling. This is highly discouraged! We try to mitigate invalid URLs as much as possible by using Entity Resolution (Merging) to link URLs together and then tagging the primary URL at the top level for key networks.
facebook_friends
Description
The number of Facebook friends the person has.
Data Type
Integer (>= 0)
Example
"facebook_friends": 3912
facebook_id
Description
The person's Facebook profile ID based on source agreement.
Data Type
String
Example
"facebook_id": "1089351304"
facebook_url
Description
The person's Facebook profile URL based on source agreement.
Data Type
String
Example
"facebook_url": "facebook.com/deseanthorne"
facebook_username
Description
The person's Facebook profile username based on source agreement.
Data Type
String
Example
"facebook_username": "deseanthorne"
github_url
Description
The person's GitHub profile URL based on source agreement.
The order of work experience in the list is determined by recency and associativity. The experience object that is tagged as experience.is_primary = True is copied over to the flattened job_ fields (see Current Job and Current Company).
Each work experience object contains the following fields:
The person's inferred years of total work experience.
Data Type
Integer (0 - 100)
Field Details
The value will be between 0 and 100.
Example
"inferred_years_experience": 7
interests
Description
The person's self-reported interests.
Data Type
Array [String]
Field Details
Each interest is cleaned (lowercased, stripped of whitespace, etc.). We don't have a canonical list of interests but we remove profanity and do some basic cleaning.
Example
"interests": [
"data"
]
job_history
Description
Additional professional positions that may have been removed or changed on resumes.
Data Type
Array [Object]
Field Details
Any additional job history information PDL has that is not included in the experience field.
Usually these are positions that have been removed or changed on resumes.
Each skill is cleaned (lowercased, stripped of whitespace, etc.). We do not always strip punctuation because it can be relevant for some skills (ex: "c++" vs "c").
We do not do any canonicalization, so "java" and "java 8.0" are considered separate skills. For this reason, we encourage our customers to use fuzzy text matching with the skills field.
The number of unique raw records contributing to this specific PDL profile.
Data Type
Integer (> 0)
Example
"num_records": 420
num_sources
Description
The number of unique sources contributing to this specific PDL profile.
Data Type
Integer (> 0)
Example
"num_sources": 72
operation_id
Description
An identifier for an operation in a Data License delivery, used for troubleshooting.
Data Type
String
Field Details
This field exists only in Data License deliveries, and allows PDL employees to identify the timestamp and operations performed on the internal data in order to return a record in a delivery.
Metadata about the version of the dataset used to retrieve this record.
Data Type
Object
Field Details
This object tracks the pervious and current dataset version, and any other persistent IDs that were merged into this record using improved entity resolution and the status of the record.
Field
Data Type
Description
contains
Array [String]
The list of IDs that have been merged into this record since the last release.
current_version
String
The current data version.
previous_version
String
The previous data version.
status
Enum (String)
The changes made to this record between the previous release and the current one. One of our Canonical Version Statuses.