A people data API returns structured information about an individual professional, job title, seniority, employer, work email, mobile number and social profiles, from an identifier you already hold, such as a name and company or a LinkedIn URL.
It is the programmable version of contact enrichment. Instead of uploading a file and downloading a result, your system asks a question and gets an answer back in milliseconds, which is what makes real-time use cases possible.
What you send and what you get
| Input you have | Typical output | Reliability |
|---|---|---|
| Work email | Full profile: name, title, employer, social | Highest, the email is a strong key |
| LinkedIn URL | Profile plus work email and mobile | High, a unique and stable identifier |
| Name plus company domain | Title, seniority, work email, mobile | Good, though common names create ambiguity |
| Name alone | Little of value | Avoid, there is no reliable disambiguation |
The pattern is consistent: the more unique your input key, the better your result. Domain-qualified inputs are worth the effort of assembling.
What it is used for
- Form enrichment. A visitor submits an email address; the API returns their role and employer before the page finishes loading, so routing and scoring happen on the first touch.
- CRM hygiene. A scheduled job re-checks records that have gone stale and refreshes the fields that changed.
- Lead scoring. Seniority and department feed the score directly, and both are unreliable when self-reported.
- Pre-send verification. Confirm a contact is still valid immediately before a sequence enrolls them, so a stale record costs a credit rather than a bounce.
- Job-change monitoring. Re-querying known contacts on a schedule surfaces the moves that signal both churn risk and new opportunity.
What to check before you commit
- Match rate on your own list. Submit 500 records from your actual segment. A vendor benchmark describes their database, not your outcome.
- Verified or inferred. Ask specifically whether returned emails were tested or pattern-generated. The two look identical in a response body.
- Mobile coverage by country. Blended global figures hide enormous regional variation. Test your territory.
- Credit policy on misses. A request that returns nothing should not be billed.
- Latency. Real-time form enrichment needs a response inside a few hundred milliseconds. Batch work does not care.
- Rate limits and bulk endpoints. A per-record endpoint hammered in a loop will hit limits. Check whether a bulk or asynchronous job endpoint exists.
- Data provenance. The provider should be able to say where a field came from. If they cannot, your compliance position is their compliance position.
Designing the integration
Three decisions determine whether this stays cheap. Cache aggressively, a record you resolved last week does not need resolving again, and a local cache with a sensible expiry is the single biggest cost saving available. Fail open, if the API is slow or down, your form should still submit; enrichment is an enhancement, not a dependency. Queue the non-urgent work, only the real-time path needs a synchronous call, and everything else should run through a queue where retries and rate limits are somebody else’s problem.
For related endpoints see our guides to the contact enrichment API and the lead enrichment API.
Cost control by design
A people data API is priced per lookup, which means the integration design determines the bill far more than the vendor rate card does. Four decisions account for most of the variance between teams paying similar rates.
| Decision | Cheap version | Expensive version |
|---|---|---|
| Caching | Local store checked before every call | Every request hits the provider |
| Scope | Only records that will be contacted | The whole database on a schedule |
| Trigger | On an event that matters | On a timer regardless of need |
| Retries | Backoff with a cap | Immediate retry loops on failure |
| Field selection | Request only fields you use | Full profile every time, where pricing is field-based |
Caching alone typically halves the bill, because the same contacts recur across campaigns, form fills and CRM refreshes. The store does not need to be sophisticated: an identifier, the resolved fields, and a timestamp is enough.
Handling the responses properly
Three response cases need explicit handling, and skipping any of them produces bugs that surface weeks later.
- Match with full data. The easy case. Write the fields, record the source and the date.
- Match with partial data. The person was found but the mobile number is missing. This must not be treated as a failure, and it must not be treated as a complete record either. Store what came back and flag the gap, or your reporting will overstate coverage.
- No match. Record that you looked and failed, with a timestamp. Without this you will re-query the same unresolvable records forever, and pay for it if your provider charges on misses.
That third case is the one that quietly wastes money. A record that cannot be resolved today is unlikely to resolve tomorrow, and a negative cache with a long expiry stops the retry loop.
Latency budgets
Where the call sits determines how much delay you can absorb, and this should be decided before you choose a provider rather than after.
Behind a web form the total budget is a few hundred milliseconds, and the call must fail open, if enrichment is slow or down, the form still submits and enrichment retries asynchronously. Enrichment should never be able to block a lead from being captured. In a CRM workflow the budget is seconds, which is comfortable. In a batch job latency is irrelevant and you should be using a bulk or asynchronous endpoint anyway, because hammering a per-record endpoint in a loop is the fastest route to a rate limit.
Frequently asked questions
What is the difference between a people data API and a company data API?
A people data API resolves an individual. A company data API resolves an organisation from a domain. Most enrichment workflows use both, usually company first to qualify the account and people second to find someone to contact.
How fresh is the data?
It varies by provider and by field. Ask for a last-verified date on the record rather than accepting a general claim of continuous updating.
Do I need one if I already upload CSVs?
Only if you need enrichment to happen without a person starting it. Real-time form enrichment, automatic CRM refresh and pre-send verification all require an API.
Related guides
- B2B data enrichment: how enrichment works and what it costs.
- Lead enrichment tools: the 8 main options compared.
- Company enrichment: turning a domain into a full account record.
- Contact enrichment API: doing it programmatically.
- Best B2B data providers: provider coverage compared.
