People Data Labs bought 5 million credits of Proxycurl's data, then passed on buying the company. So I think I know why PDL might suck (or not).
I am not neutral here. Proxycurl sold them data, NinjaPear competes with them for the same customers, and I have read their people API docs like a buyer. This is what I found. This is a guide to PDL's people API, not a roundup of every vendor.
The deal started in October 2021, when PDL's product team asked to test Proxycurl's API. They ran a few thousand calls, then a larger test, and by December they wanted 5 million credits. Their legal team sent a redline so they could commercialize the data, we signed, and the payment cleared before Christmas.
A month later, PDL reached out to work more closely, and on the call they talked about a long-term enterprise relationship. We said we were open to an acquisition, but only for cash, and they opted for the enterprise route. That was the end of the acquisition talk. This is my account, from the emails and the people who were there.
I am not telling you this to settle a score. I am telling you because it explains the bias I bring to this guide. I work at NinjaPear, the company that came after Proxycurl was sold, and I have read PDL's people API docs, pricing page and field schema the way a buyer would.
PDL's people API is not one product but three: Enrichment, Search and Identify, each with its own job, rate limit and bill. The docs make them look like one API, and the pricing page makes them look simple; neither is true.
This is the guide I wish I had before I started reading.
What does PDL's people API do?
PDL sells a database, not a scraper. It is a large, compiled set of people and company records, and you query it by sending a person or a filter and getting a profile back. The deal I mentioned earlier happened at Proxycurl, which was later sold. NinjaPear is the company that came after it, built from what we learned at Proxycurl. That is where I learned how PDL buys data before I read its docs as a buyer.
The people API lives at https://api.peopledatalabs.com, the live endpoints run on v5, and every request needs an API key in the X-Api-Key header. Responses are JSON, including errors.
The database behind it is big: PDL's Person Stats page, checked on 4 November 2026, lists 2,468,465,575 profiles in the All Dataset, plus 817,838,859 with a profile URL, 592,188,754 with an email, 763,695,828 with a phone, and 4,301,071 with a GitHub URL. Those are counts, not fill rates, because a person can be in the All Dataset and still have a null in the field you need, which matters more than the headline number.
The API has three ways to ask: Enrichment for one person, Search for a list, and Identify for a fuzzy match. Although they share a base URL and an auth header, they do not share an input shape, a rate limit or a billing unit, which is the thing the product page does not make obvious.
I read the docs the first time and saw one API, which was my mistake: it is three products with one name, and the rest of this guide is the order I should have read them in. I did not have a paid PDL key for this piece, so I read the docs, the pricing page and the schema; the request examples use PDL's documented parameters, not a paid call. I say that so you know what is tested and what is documented.
How do you look up one person?
If you have one person and at least one strong identifier, you want Enrichment, which is a one-to-one match against the database.
Endpoint: POST https://api.peopledatalabs.com/v5/person/enrich. PDL documents the full Person Enrichment API.
To use it, you send what you know: PDL accepts name, first_name, last_name, location, company, school, phone, email, profile, lid, birth_date and pdl_id. More input usually means a better match, and you can set min_likelihood to put a floor on the match score, required to demand a field before a 200, and data_include to limit the response to the fields you need. Enrichment's rate limit depends on your plan, so check the docs before you loop it.
This is the request shape PDL documents:
curl -X POST https://api.peopledatalabs.com/v5/person/enrich \
-H "X-Api-Key: $PDL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"email": "[email protected]",
"min_likelihood": 6,
"data_include": "full_name,job_title,job_company_name"
}'
A match is a 200 with a data object, and no match is a 404. You pay per successful match, so a 404 is free here, which is the important difference from Identify.
The trap is using Enrichment for a list, because it is a one-to-one call and 500 names would mean 500 calls in a loop. PDL does have a bulk endpoint that takes up to 100 enrichments per request, but the better question is whether you should be using Search at all, which is the next section.
One more thing: Enrichment returns the best match, not every possible match. If you are not sure the person is in the database, set min_likelihood and check the likelihood score, because a 200 does not mean the match is right; it means PDL found something.
How do you pull a list of people?
Search is the endpoint for a list, not a lookup, because it runs a filter over the full dataset instead of matching one person.
Endpoint: POST https://api.peopledatalabs.com/v5/person/search. PDL documents the full Person Search API.
You send an Elasticsearch 7.7 query or a SQL query, set size to the number of records you want from 1 to 100, and use scroll_token to get the next page. The older from parameter works up to 9,999, but PDL says it is not recommended and will not be supported long term.
You pay per record returned, so a size: 100 call can consume 100 credits, which is the budget control. Search is capped at 10 requests per minute, so the page size and the page count both matter. If you set size to 100 and run 10 pages, you just bought 1,000 records, and that is the number you need to put in the plan.
The API returns a 200 even when it finds nothing, so check total before you assume the query failed. The SQL option is convenient, but PDL ignores column selection and LIMIT in the SQL string, so use size to control the response.
The trap is looping Enrichment for a list, because Enrichment is for one person and Search is for a set. If you have a filter, use Search; if you have a list of names, you either need Enrichment one by one or you need to turn the names into filters, which is where most teams burn credits.
How do you find someone with only a name and a city?
Identify is the fuzzy one, and you use it when you have partial identity signals and need candidates rather than a single best match.
Endpoint: POST https://api.peopledatalabs.com/v5/person/identify. PDL documents the full Person Identify API.
You send a name, a company, a location, a phone, an email or a profile URL, and PDL returns up to 20 scored candidates. The rate limit is 10 calls per minute, and you pay per call whether it returns a 200 or a 404, which is the difference from Enrichment: a miss costs you here.
The trap is treating Identify like Enrichment, because it is not a one-to-one match but a shortlist you still have to review. If you need one record and you have a strong identifier, use Enrichment; if you have a name and a city and no email, Identify is the right tool, but you have to budget for the misses.
I would set a rule before I run it: how many candidates am I willing to review, and what score is good enough. Without that rule, Identify becomes a list of maybes, and the 20-candidate cap is useful because it forces you to decide what a match means.
What does PDL cost, and what do you get for it?
This is the part I got wrong first, because I looked at the headline price and thought I understood the bill. The same word, credit, means different things on the three endpoints, and the difference is large enough to change which endpoint you use.
The entry plan, checked on 4 November 2026, is $98 a month for 350 credits, which is $0.28 per credit, and the tier gets cheaper as you buy more: 2,501 to 5,000 credits at $0.265, 5,001 to 8,333 at $0.25. Identify has its own tiers: 200 to 499 at $0.55, 500 to 999 at $0.525, 1,000 to 4,167 at $0.50.
Here is what 1,000 units look like at the entry rate:
| Job | Endpoint | Billing unit | 1,000 units |
|---|---|---|---|
| One person | Enrichment | Per successful match | $280 |
| A list | Search | Per record returned | $280 |
| A name and a city | Identify | Per call, 200 or 404 | $550 |
If every Identify call returns 20 candidates, the cost per candidate is $0.0275 at the entry rate, but if it returns a 404 you still pay, and that is the number to put in your budget.
The free plan gives you 100 credits a month, but it obfuscates contact data, so if you need an email or a phone, the free plan is a demo rather than a production plan. The paid plan returns contact data, but you still need to check which fields are in the base bundle and which are premium.
The second half of the cost is the record: PDL's All Dataset, as of 4 November 2026, has 2,468,465,575 profiles, but that does not mean every profile has the field you need. The Resume Dataset has 817,838,859 profiles with a profile URL, and the Email Dataset has 592,188,754 with an email, but those are counts, not fill rates, and a record can be in the dataset with a null in the field you need.
This is why I would run the 100-record test before I paid for a plan: pull 100 rows from your own list, run them through the endpoint you think you need, and count the 200s, the 404s and the fields that come back empty. That is the only fill rate that matters.
Should you use PDL?
PDL is a good tool for a specific job: searching a large compiled dataset with constraints. If you need to find people by title, company size, funding, location or technology, PDL is built for that, and Search is the strongest part of the product because the dataset is large and the filters are expressive.
It is weaker when you need a live profile or a field that is not in the bundle, because PDL is a compiled dataset rather than a live scrape. If you need today's title, today's company or a verified email, test the record before you rely on it, and ask about the refresh date because the dataset count does not tell you how fresh the record is.
I would not use PDL for one-off lookups, because the pricing is built for volume and the docs assume you are integrating. If you need 20 records, the setup cost is higher than the value; if you need 20,000, the economics change.
Here is the decision table I would use:
| Your job | PDL fit | Why |
|---|---|---|
| Search a large dataset with filters | Strong | Search is the core product. |
| Enrich one person from a strong identifier | Good | Enrichment is simple, and 404s are free. |
| Find a person from a name and a city | Good, with a budget | Identify works, but misses cost. |
| Get a live profile or a verified email today | Weak | PDL is compiled, not live. Test freshness. |
| Run 20 one-off lookups | Weak | The setup and pricing are built for volume. |
The five checks before you build: match the endpoint to the job, price the billing unit rather than the headline, test 100 records from your own list, check that the fields you need are in the base bundle, and decide whether freshness or coverage matters more. If you do those five things, you will know more about PDL than the pricing page tells you, and that is the guide I wish I had before I started reading.
If you need a live profile, look at a live API. NinjaPear's employee API is one option, and you can compare the request shape in the NinjaPear API reference. Test it with the same 100-record test; I work there, so discount that accordingly. If you need company data instead, NinjaPear's company API covers that. And if you want a broader comparison, I wrote about the best company data APIs according to Reddit.
