Person Data API: What It Returns and How Recruiting Teams Can Judge One

A person data API (application programming interface) is a service your software calls to find people or fill in their details. Your applicant tracking system (ATS) or internal tool sends a request, and the API returns a structured record. That record can include a name, current title and employer, work history, education, skills, location, profile links, and sometimes a work email or phone number.

Recruiting teams encounter person data APIs when a developer wants to automatically fill ATS records, or when a vendor offers API access to its data. Some vendors call it a people data API. Knowing what it returns and how to test the data helps you decide whether one belongs in your workflow. "Person API" can also mean an organization's own staff directory, which isn't the subject here.

What a person record contains

A person record is a set of fields about one individual, grouped into categories that go out of date at different rates. Providers name their fields in their own ways, but the groups below cover what a response returns in broad terms.

• Identity and links: Full name, alternate spellings, and links to public professional profiles. A profile link is often the most specific identifier in the record.
• Current role: Title, employer, seniority, and start date. This group changes with every promotion or move, so it goes stale faster than most of the record.
• Work history: Previous employers, titles, and dates. Older entries rarely change, although a new one is added each time the person moves.
• Education and skills: Schools, degrees, certifications and listed skills. Education changes least of any group, while skills lists can grow as people update their profiles.
• Location: City, region and country, which can lag behind a recent move.
• Contact details: Work email, personal email or phone, where the provider offers them. A work email often stops working when someone leaves an employer, so this group needs checking as often as the current role.

When you review a sample response, notice which groups come back filled for the candidates you recruit, not just which fields the documentation lists.

Search, lookup, identify and bulk requests

Providers offer some combination of four request types, and each answers a different question. A search request, the core of a people search API, starts with criteria such as title, skills, and location and returns matching people. A lookup or enrichment request starts from one person you already know about and fills in the rest of the record. That second job is what a person lookup API does.

The table shows what each request type takes, what it returns, and where it fits in recruiting work.

Lookup and identify can overlap, since some providers return several scored matches from an ordinary lookup. Bulk requests often carry their own pricing and limits, which matters when you plan to refresh thousands of records.

How a person data API matches a record to the right person

A person data API compares the details you send with its records, and the more unique your input, the more reliable the match. A profile URL or a work email points to one person, while a name and an employer can describe several. Many providers return a confidence or likelihood score with each match to show how sure the system is.

Suppose a recruiter sends a lookup with only a common name and a large employer. The response could include several possible people at that company, and the top result might not be the candidate in the ATS. The recruiter compares the returned work history with the resume on file and leaves the record alone if nothing lines up.

For that reason, teams that connect an API to an ATS often set a confidence threshold. Matches above it fill empty fields automatically, and matches below it go to a recruiter to check. Set it by how costly a wrong match would be. A mistaken skill tag does little harm, but a wrong email reaches a stranger.

A work email from a confident match can still be out of date, so the routine for checking one lookup before you send applies here too.

Why person records go out of date

Person records go out of date because people change jobs, titles, and email addresses, and a provider only reflects those changes after it collects them again. BLS tenure data put median tenure with the current employer at 4.1 years for U.S. wage and salary workers in January 2026. In the same survey, 20.6% had been with their employer a year or less.

Those figures describe time with an employer, not how often profiles change, but they help explain stale provider data. With about one in five workers in their job a year or less, a record collected over a year ago may list a former employer.

A record is more useful when it tells you how old it is. Ask whether each record or field carries a "last updated" date from the provider. Keep your own last-checked date too, so you know which records to refresh first. Education and older work history can go years without a refresh, while current role and contact details need a closer eye.

How recruiting teams use person data in their systems

Recruiting teams use a person data API wherever software needs details about people without a recruiter typing them in.

• Enriching ATS records on arrival: When an application arrives with only a name and email, a lookup can add title, employer, and profile links for the screening recruiter. Keep the candidate's own resume as the main record, since enriched fields are the provider's best match rather than something the candidate told you.
• Powering search inside internal tools: Some agencies and in-house teams build search screens on top of a search request, so recruiters can query inside their own system.
• Refreshing old talent pool records: A bulk request can flag saved candidates who have changed employer or title. That helps you decide whom to contact first during talent pool maintenance.
• Checking client contacts: Agency recruiters can run the same lookups on hiring managers in a CRM (customer relationship management system). Business development outreach then reaches whoever holds the role now. The standards for usable B2B contact data apply to those records as well.

An API makes the most sense when data needs to flow into a system automatically and at volume, and someone can maintain the connection. If recruiters mostly look people up one at a time, a self-serve tool gives them similar data without development work. Choosing whether to build an integration or buy access has its own trade-offs, and an API is only one of the sourcing tools recruiters use.

Check a provider's data before you sign

The most reliable way to judge a provider is to test its data on people your team already knows, and to ask the questions below.

• Coverage for your roles and regions: A provider can cover one profession or country well and another thinly. Test with a sample drawn from the searches you run.
• Freshness and update dates: Ask how often records are refreshed and whether each response shows a last-updated date.
• Field fill rates on your sample: Count how often the fields you need come back filled, which a documentation field list can't tell you.
• Match quality and confidence scores: Check whether the top match is the right person and whether low scores align with incorrect matches.
• Data sourcing, deletion and opt-out: Ask where the data comes from and how the provider handles deletion and opt-out requests.
• Pricing model: Providers may charge per record, per call, through credits, or by subscription. Ask whether calls that return no match are billed, because that changes the cost of a lookup-heavy workflow.
• Rate limits and bulk options: Check how many calls you can make per hour or day, and whether bulk jobs run separately.
• Documentation and support: Your developer will judge the documentation, and you can ask who to contact when matches look wrong.

A pilot brings these checks together. Send the provider records your team has already confirmed and compare what comes back field by field. Before you share those records, check that your privacy notice and vendor agreement allow it. Because you already know the right answers, any wrong matches, empty fields or outdated titles are easy to spot, which gives you a concrete basis for comparing providers.

Privacy and FCRA rules for recruiting use

Privacy laws shape how providers collect personal data, and the Fair Credit Reporting Act (FCRA) shapes how hiring teams use it. Under California's Delete Act, a business that knowingly collects and sells personal information about people it has no direct relationship with may count as a data broker. Data brokers must register with the state. Beginning August 1, 2026, they must also check California's deletion platform at least once every 45 days and process deletion requests, subject to limited exceptions.

It's reasonable to ask a provider whether it's registered in California and how it handles those requests. Other states have their own privacy laws.

The FCRA draws a separate line based on use. Under the FCRA definitions, a consumer report includes information about a person's character, general reputation or personal characteristics used as a factor in eligibility for employment purposes. The law defines employment purposes as evaluating someone for employment, promotion, reassignment, or retention.

Because the definition depends on use, a sensible practice is to keep person data API results for finding and contacting people. Anything that informs a decision about a candidate belongs in your background check process. Whether a provider's data falls under the FCRA is a question for counsel. Collect only the contact details your outreach needs, and draw no conclusions about protected characteristics such as age or health from enriched data.

Start with known records before you connect an API

Each part of this topic comes back to whether a returned record describes the right person in their current role. Request types define what you can ask for, and matching and confidence scores show how much you can trust each answer. Update dates tell you how long that answer stays useful, and privacy and FCRA rules limit what you do with it. Before anyone signs a contract or writes integration code, run a sample of records your team has already confirmed through each provider you're considering.