Skip to main content

Overview

This page details the Person Data that we provide through our Person APIs, such as Person Enrichment and Person Search.
Field AvailabilityNot all fields are available in all bundles.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

Identifiers


first_name

Field Details

The person’s first name.

Example

JSON

full_name

Field Details

The first and the last name fields appended with a space.

Example

JSON

id

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. See Persistent IDs for more information.

Example

JSON

last_initial

Field Details

The first letter of the person’s last name.

Example

JSON

last_name

Field Details

The person’s last name.

Example

JSON

middle_initial

Field Details

The first letter of the person’s middle name.

Example

JSON

middle_name

Field Details

The person’s middle name.

Example

JSON

name_aliases

Field Details

Any associated names or aliases besides the primary one used in the full_name field.
Sort OrderName aliases are sorted with the primary alias first. The remaining aliases are sorted by num_sources, last_seen, first_seen, full_name, all in reverse order (highest first, most recent, Z→A):
  1. Primary name first
  2. num_sources (highest first)
  3. last_seen (most recent first)
  4. first_seen (most recent first)
  5. full_name (Z→A)

Example

JSON

Contact Information


emails

Field Details

Note This array contains historical email addresses and should not directly be used for email outreach. Recommended Alternatives
Each email associated with the person will be added to this list as its own object.
Sort OrderEmails are sorted first by last_seen, then by first_seen, email , all in reverse order (most recent first, Z→A):
  1. last_seen (most recent first)
  2. first_seen (most recent first)
  3. email (Z→A)

Example

JSON

mobile_phone

Field Details

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.

Example

JSON

personal_emails

Field Details

The list of all emails tagged as type = personal.
Sort OrderPersonal emails are sorted with the recommended personal email first. The remaining emails are sorted in the same order as the emails array:last_seen, then by first_seen, email, all in reverse order (most recent first, Z→A):
  1. Recommended personal email first
  2. last_seen (most recent first)
  3. first_seen (most recent first)
  4. email (Z→A)

Example

JSON

phone_numbers

Field Details

For more detailed metadata on individual phone numbers, see the phones field.
Sort OrderPhone numbers are sorted with any mobile phone numbers first. The rest of the array is sorted by num_sources, last_seen, first_seen, all in reverse order and using the E.164 format (highest first, most recent first):
  1. Mobile phone numbers first
  2. num_sources (highest first)
  3. last_seen (most recent first)
  4. first_seen (most recent first)

Example

JSON

phones

Field Details

Each phone number object in this list will contain the following information.
Sort OrderPhones are sorted with any mobile phone numbers first. The rest of the array is sorted by num_sources, last_seen, first_seen, all in reverse order and using the E.164 format (highest first, most recent first):
  1. Mobile phone numbers first
  2. num_sources (highest first)
  3. last_seen (most recent first)
  4. first_seen (most recent first)

Example

JSON

Field Details

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.

Example

JSON

work_email

Field Details

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

Example

JSON

Current 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

Example

JSON

job_company_facebook_url

Example

JSON

job_company_founded

Example

JSON

job_company_employee_count

Example

JSON

job_company_id

Example

JSON

job_company_industry

Example

JSON

job_company_industry_v2

Example

JSON

Details

Industry v2 is the self-reported industry from an expanded list of Canonical V2 Industries. If no industry is found, the field will be null

job_company_inferred_revenue

Example

JSON

job_company_linkedin_id

Example

JSON

job_company_linkedin_url

Example

JSON

job_company_location_address_line_2

Example

JSON

job_company_location_continent

Example

JSON

job_company_location_country

Example

JSON

job_company_location_geo

Example

JSON

job_company_location_locality

Field Details

The person’s current company’s headquarters’ locality, typically the city or local place name for the headquarters address. Examples: san francisco, new york, toronto.

Example

JSON

job_company_location_metro

Example

JSON

job_company_location_name

Example

JSON

job_company_location_postal_code

Example

JSON

job_company_location_region

Example

JSON

job_company_location_street_address

Example

JSON

job_company_name

Example

JSON

job_company_size

Example

JSON

job_company_ticker

Example

JSON

job_company_total_funding_raised

Example

JSON

job_company_twitter_url

Example

JSON

job_company_type

Example

JSON

job_company_website

Example

JSON

Current Job

These fields describe the person’s most recent work experience.

inferred_salary

Field Details

Must be one of our Canonical Inferred Salary Ranges.

Example

JSON

job_last_changed

Field Details

An update is the time when the current employment information is modified in the record.
Limitations of Observed DataThis 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

JSON

job_last_verified

Field Details

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

JSON

job_onet_code

Field Details

The 8-digit O*NET code for the person’s current job title, following the current Standard Occupational Classification guidelines. For more details, see the O*NET Field Overview.

Example

JSON

job_onet_major_group

Example

JSON

job_onet_minor_group

Example

JSON

job_onet_broad_occupation

Example

JSON

job_onet_specific_occupation

Example

JSON

job_onet_specific_occupation_detail

Field Details

This field represents 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. For more details, see the O*NET Field Overview.

Example

JSON

job_start_date

Example

JSON

job_summary

Field Details

The summary is lowercased, but otherwise kept as-is from the raw source.

Example

JSON

job_title

Field Details

The person’s current job title.

Example

JSON

job_title_class

Field Details

Each class in the list will be one of our Canonical Job Title Classes.

Example

JSON

job_title_levels

Field Details

Each level in the list will be one of our Canonical Job Title Levels.

Job Title Levels Hierarchy from “least important” to “most important”:

UnpaidTrainingEntryManager>SeniorPartnerDirectorVPOwnerCXO
Note: The cxo level is a catch-all for “Chief __ Officer” roles, so a CEO, CIO, CTO, etc. will all have job_title_levels: ["cxo"].

Example

JSON

job_title_role

Field Details

The value will be one of our Canonical Job Roles.
Major Update as of v29.1 (February 29.1)In v29.1 (February 2024) we made significant improvements to our role and sub_role categorizations and updated many of the canonical values associated with these fields.Please see our February 2025 Release Notes (v29.1)for further information.

Example

JSON

job_title_sub_role

Field Details

The value will be one of our Canonical Job Sub Roles. Each subrole maps to a role. See Mapping Job Title Class to Roles to Subroles for the complete list.
Major Update as of v29.1 (February 29.1)In v29.1 (February 2024) we made significant improvements to our role and sub_role categorizations and updated many of the canonical values associated with these fields.Please see our February 2025 Release Notes (v29.1)for further information.

Example

JSON

Demographics


birth_date

Field Details

If this field exists, birth_year will agree with it.

Example

JSON

birth_year

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

JSON

sex

gender was renamed to sex in v26.0In 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).Please see our April 2024 Release Announcement (v26.0) for further information.

Field Details

The value will always be one of our Canonical Sex.

Example

JSON

languages

Field Details

The languages listed are based on user input, we do not verify them.
Sort OrderLanguages are sorted by proficiency first, followed by name, all in reverse order (highest proficiency first, Z→A):
  1. proficiency (highest first)
  2. name (Z→A)

Example

JSON

Education


education

Field Details

The education objects associated with this person profile, which, when output in CSV format, have indexing based on recency and associativity. Each education object in the list will include the following data:
Sort OrderEducation entries are sorted first by start_date, then by end_date. If dates are identical, then sorting occurs by school.name, followed by majors, minors and degrees, all in reverse order (most recent first, Z→A):
  1. start_date(most recent first)
  2. end_date (most recent first)
  3. school.name (Z→A)
  4. countriesmajors (Z→A)
  5. minors (Z→A)
  6. degrees (Z→A)

education.school
To tap into our school matching logic, use our School Cleaner API to retrieve possible school values.

Example

JSON

Location

For more information on our standard location fields, see Common Location Fields.

countries

Sort OrderCountries are sorted using location sort order, with any duplicate countries removed.Location Sort OrderLocations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):
  1. Primary location first
  2. Sort by first_seen (most recent first)
  3. Sort by last_seen (most recent first)
  4. Sort by location_name (Z→A)
  5. Sort by street_address (Z→A)
  6. Sort by address_line_2 (Z→A)

Example

JSON

location_address_line_2

Example

JSON

location_continent

Example

JSON

location_country

Example

JSON

location_geo

Example

JSON

location_last_updated

Field Details

An update is the time when either new information is added to the record or existing information is validated.

Example

JSON

location_locality

Field Details

The locality for the person’s current address, typically the city or local place name component of the address. Examples: berkeley, boston, cambridge.

Example

JSON

location_metro

Example

JSON

location_name

Example

JSON

location_names

Sort OrderLocation names are sorted by location order with duplicate names removedLocation Sort OrderLocations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):
  1. Primary location first
  2. Sort by first_seen (most recent first)
  3. Sort by last_seen (most recent first)
  4. Sort by location_name (Z→A)
  5. Sort by street_address (Z→A)
  6. Sort by address_line_2 (Z→A)

Example

JSON

location_postal_code

Example

JSON

location_region

Example

JSON

location_street_address

Example

JSON

regions

Sort OrderRegions are sorted by location order, with any duplicate regions removed.Location Sort OrderLocations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):
  1. Primary location first
  2. Sort by first_seen (most recent first)
  3. Sort by last_seen (most recent first)
  4. Sort by location_name (Z→A)
  5. Sort by street_address (Z→A)
  6. Sort by address_line_2 (Z→A)

Example

JSON

street_addresses

Field Details

Each address associated with the person will be added to this list as its own object. In addition to the Common Location Fields, street_addresses will also include:
Sort OrderStreet addresses are sorted by location order.Location Sort OrderLocations are sorted by primary location first. The remaining locations are sorted by first_seen, last_seen, location_name, street_address, then address_line_2 in descending order (most recent first, Z→A):
  1. Primary location first
  2. Sort by first_seen (most recent first)
  3. Sort by last_seen (most recent first)
  4. Sort by location_name (Z→A)
  5. Sort by street_address (Z→A)
  6. Sort by address_line_2 (Z→A)

Example

JSON

Lower Confidence Data

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

Field Details

The dates in this field use the same format as the birth_date field.
Sort OrderPossible birth dates are sorted by num_sources, last_seen, first_seen, birth_date, all in reverse order (highest first, most recent first):
  1. num_sources (highest first)
  2. last_seen (most recent first)
  3. first_seen (most recent first)
  4. birth_date (most recent first)

Example

JSON

possible_emails

Field Details

This field uses the same format as the emails field.
Sort OrderPossible emails are sorted by last_seen, first_seen, email, all in reverse order (most recent first, Z→A):
  1. last_seen (most recent first)
  2. first_seen (most recent first)
  3. email (Z→A)

Example

JSON

possible_location_names

Field Details

This field uses the same format as the location_names field. Possible locations are inferred based on phone area codes, university location, and other associations.
Sort OrderPossible locations are sorted by first_seen, last_seen, location.name, all in reverse order (most recent first, Z→A):
  1. first_seen (most recent first)
  2. last_seen (most recent first)
  3. location.name (Z→A)

Example

JSON

possible_phones

Field Details

This field uses the same format as the phones field.
Sort OrderPossible phones are sorted by num_sources, last_seen, first_seen, all in reverse order and using the E.164 format (highest first, most recent first):
  1. num_sources (highest first)
  2. last_seen (most recent first)
  3. first_seen(most recent first)

Example

JSON

possible_profiles

Field Details

This field uses the same format as the profiles field.
Sort OrderPossible profiles are sorted first by return status codes (200 > unknown > 404). The array is then sorted by number of profiles globally, last_seen, first_seen, username, id, all in reverse order (highest first, most recent first, Z→A):
  1. Status Codes:
    • Profiles with 200 return status codes are first
    • Profiles with unknown return status codes come next
    • Profiles with 404 return status codes are placed last
  2. Number of profiles globally (highest first)
  3. last_seen (most recent first)
  4. first_seen (most recent first)
  5. username (Z→A)
  6. id (Z→A)

Example

JSON

possible_street_addresses

Field Details

This field uses the same format as the street_addresses field.
Sort OrderPossible street addresses are sorted by first_seen, last_seen, location.name, location.street_address, location.address_line_2, all in reverse order (most recent first, Z→A):
  1. first_seen (most recent first)
  2. last_seen (most recent first)
  3. location.name (Z→A)
  4. location.street_address (Z→A)
  5. location.address_line_2 (Z→A)

Example

JSON

Social Presence

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

Example

JSON

facebook_id

Example

JSON

facebook_url

Example

JSON

facebook_username

Example

JSON

github_url

Example

JSON

github_username

Example

JSON

linkedin_connections

Field Details

Typically between 0-500.

Example

JSON

linkedin_id

Example

JSON

linkedin_url

Example

JSON

linkedin_username

Example

JSON

profiles

Field Details

Each profile associated with the person will be added to this list as its own object.
Sort OrderProfiles are sorted with the primary profiles listed first (facebook, linkedin, twitter, and github, in that order). The rest of the array is then sorted by status codes (200 > unknown > 404), number of profiles globally, last_seen, first_seen, username, id, all in reverse order (highest first, most recent first, Z→A):
  1. Primary profiles first
    1. Facebook
    2. LinkedIn
    3. Twitter
    4. Github
  2. Status Codes:
    • Profiles with 200 return status codes are first
    • Profiles with unknown return status codes come next
    • Profiles with 404 return status codes are placed last
  3. Number of profiles globally (highest first)
  4. last_seen (most recent first)
  5. first_seen (most recent first)
  6. username (Z→A)
  7. id (Z→A)

Example

JSON

twitter_url

Example

JSON

twitter_username

Example

JSON

PDLScores™

PDLScores™ are generated scoring fields that help evaluate and prioritize Person profiles. For GA availability, bundle information, example responses, and common workflows, see PDLScores™ for Person Data.
Resume Slice OnlyPDLScores™ and their associated score factors are only available on records in the Resume Slice of the Person dataset. Profiles outside the Resume Slice return null for these fields.

profile_score

This field is only available on records in the Resume Slice. Profiles outside the Resume Slice return null.
For GA availability, bundle information, and example responses, see PDLScores™ for Person Data.

Field Details

The profile_score helps identify profiles that appear to represent real people. PDL evaluates signals such as profile completeness, profile age, LinkedIn URL validity, and connection count. This field returns one of the following values:

Example

JSON

profile_score_factors

These score factors are only available on records in the Resume Slice. Profiles outside the Resume Slice return null.
For GA availability, bundle information, and example responses, see PDLScores™ for Person Data.

Field Details

The profile_score_factors object provides additional context for customers who want to build custom filtering, ranking, or review logic around profile_score. These factors are available through the premium PDL Score Factors bundle. PDL does not expose the raw score used to assign the final profile_score bucket.

Example

JSON

profile_score_factors.attribute_fill_rate

Field Details

This factor measures how filled out the profile is across selected resume attributes, such as education, experience, headline, summary, skills, interests, certifications, and custom LinkedIn slug. Higher values indicate that more selected attributes are present on the profile.

Example

JSON

profile_score_factors.profile_age_months

Field Details

This factor measures the number of months since PDL first observed the profile. Older profiles generally provide a stronger historical signal that the profile represents a legitimate professional identity.

Example

JSON

profile_score_factors.has_valid_url

Field Details

This factor evaluates the LinkedIn URL associated with the profile.

Example

JSON

profile_score_factors.meets_connection_threshold

Field Details

This factor evaluates whether the profile meets PDL’s LinkedIn connection threshold.

Example

JSON

activity_score

This field is only available on records in the Resume Slice. Profiles outside the Resume Slice return null.
For GA availability, bundle information, and example responses, see PDLScores™ for Person Data.

Field Details

The activity_score helps identify profiles that appear to be actively maintained. PDL evaluates signals such as recent resume activity, connection count changes, and user-edited profile changes. This field returns one of the following values:

Example

JSON

activity_score_factors

These score factors are only available on records in the Resume Slice. Profiles outside the Resume Slice return null.
For GA availability, bundle information, and example responses, see PDLScores™ for Person Data.

Field Details

The activity_score_factors object provides additional context for customers who want to build custom activity, routing, prioritization, or suppression logic around activity_score. These factors are available through the premium PDL Score Factors bundle. PDL does not expose the raw score used to assign the final activity_score bucket.

Example

JSON

activity_score_factors.connection_change

Field Details

This factor evaluates whether PDL has observed a change in the profile’s LinkedIn connection count across recent releases.

Example

JSON

activity_score_factors.profile_change

Field Details

This factor evaluates whether PDL has observed an update to user-edited profile fields such as headline, summary, experience, education, location, certifications, skills, or interests.

Example

JSON

activity_score_factors.months_since_last_end_resume

Field Details

This factor evaluates resume recency by looking at experience and education activity. If the profile has an active job or active education, this field is null. Otherwise, it reflects the number of months since the latest end date on the profile’s resume data. Lower values generally indicate more recent resume activity.

Example

JSON

Work History


certifications

Field Details

The certifications listed are based on user input, we do not verify them.
Sort OrderCertifications are sorted first by start_date, then by end_date and finally by name, all in reverse order (most recent first, Z→A):
  1. start_date (most recent first)
  2. end_date (most recent first)
  3. name (Z→A)

Example

JSON

experience

Field Details

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:
Sort OrderExperience entries are sorted with the primary experience first. The remaining entries are then sorted by start_date, end_date, company.name, and title.name, all in reverse order (most recent first, Z→A):
  1. Primary Experience (is_primary = True )
  2. start_date (most recent first)
  3. end_date (most recent first)
  4. company.name (Z→A)
  5. title.name (Z→A)

experience.company
The fields in experience.company map to the corresponding fields in our Company Schema. The same parsing and formatting logic apply.
experience.title
See the corresponding Current Job fields for more details on the information included and formatting of these fields.
Sort Order (experience.title.levels)Title levels are sorted from most important to least important based on the following ranking:
  1. cxo (first)
  2. owner
  3. vp
  4. director
  5. partner
  6. senior
  7. manager
  8. entry
  9. training
  10. unpaid (last)

Example

JSON

headline

Field Details

The self-written headline tied to the person profile (often a LinkedIn headline). The summary is lowercased, but otherwise kept as-is from the raw source.

Example

JSON

industry

Field Details

A person’s industry is determined based on their tagged personal industries and the industries of the companies that they have worked for. The value will be one of our Canonical Industries.

Example

JSON

inferred_years_experience

Field Details

The value will be between 0 and 100.

Example

JSON

interests

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.
Sort OrderInterests are sorted alphabetically (from A→Z)

Example

JSON

job_history

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.
Sort OrderJob history entries are sorted by start_date, end_date, company.name, and title.name, all in reverse order (most recent first, Z→A):
  1. start_date (most recent first)
  2. end_date (most recent first)
  3. company.name (Z→A)
  4. title.name (Z→A)

Example

JSON

skills

Field Details

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.
Sort OrderSkills are sorted alphabetically (from A→Z)

Example

JSON

summary

Field Details

The self-written summary tied to the person profile (often a LinkedIn summary). The summary is lowercased, but otherwise kept as-is from the raw source.

Example

JSON

PDL Record Information & Metadata


dataset_version

Field Details

This field currently exists in Person Enrichment API responses. Note: This number corresponds to the data release number, not the API release number.

Example

JSON

first_seen

Example

JSON

num_records

Example

JSON

num_sources

Example

JSON

operation_id

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.

Example

JSON