Quick summary
No provider led every dimension. The strongest result depends on whether a workflow needs one person per account, broad co-founder coverage, clean current-role data, incremental waterfall contacts, or the lowest cost per usable outcome.
- CompanyEnrich resolved 442 of 502 companies, or 88.0%, the highest company coverage in this sample.
- Crustdata found 825 correct people, the largest correct-person count and 88.4% of the pooled reference.
- Apollo contributed 15 unique finds, more than any other provider in this run.
- Crustdata returned zero stale profiles, while stale counts ranged from 5 to 31 for the other providers.
- CompanyEnrich had the lowest calculated unit cost, at $0.0049 per resolved company and $0.0027 per correct person under the benchmark's pricing assumptions.
| Benchmark scope | Value |
|---|---|
| Companies tested | 502 |
| Providers compared | 7 |
| Included candidate rows | 5,648 |
| Pooled correct person-company pairs | 933 |
| Benchmark repository | GitHub |
What Does This People Search API Benchmark Measure?
The benchmark measures one narrow, practical search task: given a known company, find people who currently hold a CEO or founder role there.
That scope matters. A broad people data platform may support dozens of filters, datasets, and enrichment endpoints. This test does not attempt to score all of them. It evaluates whether each tested people search endpoint can return usable LinkedIn profiles for one common GTM and data-product workflow.
The comparison has three layers.
1. Company coverage
Company coverage measures whether the provider returned at least one candidate classified from the Harvest snapshot as a current CEO or founder for each target company. This is the most useful metric when a workflow needs one usable decision-maker per account.
The company-focused analysis also separates two failure modes:
- No candidates: the provider returned no valid LinkedIn candidate for the company.
- Results but no correct: the provider returned candidates, but none were classified as a current CEO or founder at the target company.
Those outcomes are operationally different. An empty result can trigger a fallback provider immediately. A plausible but incorrect result may enter a CRM, reach an outbound sequence, or require manual review before anyone notices the problem.
2. People coverage and result outcomes
People coverage measures how many of the 933 pooled correct person-company pairs each provider found. The pool contains every correct pair returned by at least one of the seven providers.
The people-focused analysis also counts:
- Returned candidates after normalization and deduplication.
- Correct current CEOs and founders.
- Unique finds returned by only one provider.
- Stale former CEOs and founders.
- Wrong-title, wrong-company, and wrong-both results.
- Ambiguous or unverified results.
This prevents a provider from looking strong merely because it returned a long list. More results are useful only when those results include more correct people without creating an excessive review burden.
3. Pricing efficiency
The pricing comparison estimates the cost per resolved company and cost per correct person. It uses a fixed price-per-credit snapshot and either reported or estimated credit consumption, depending on what each provider exposed during the run.
Pricing is the least interchangeable dimension. Providers define credits differently, package plans differently, and may negotiate custom rates. The cost table should therefore be read as a calculation for this benchmark run, not as a permanent statement about every customer's invoice.
What to do: Start with the outcome that matches your workflow. Use company coverage when one contact per account is enough, people coverage when co-founder breadth matters, and unit cost when the workflow runs at meaningful volume.
How Was the People Search API Benchmark Run?
The benchmark was designed so each provider faced the same target companies and every returned candidate passed through the same downstream verification logic. The public GitHub repository provides tooling for collecting fresh provider data and running a new benchmark. It does not include the original benchmark data or result artifacts used for this page.
1. Build and freeze the company cohort
The cohort contains 502 companies from the Winter 2024, Spring 2024, Summer 2024, and Fall 2024 Y Combinator batches. It was assembled from the Y Combinator company directory in June 2026.
The initial extraction contained 591 companies. The final benchmark retained companies marked active by YC that also had a LinkedIn company page. The 502-company cohort was frozen for this run but is not bundled in the public repository. A fresh run can assemble and freeze its own cohort.
This cohort is intentionally specific. Recently funded technology startups often have multiple founders, changing executive roles, rebrands, and uneven data coverage. That makes the set useful for testing current founder discovery, but it does not represent every market segment.
2. Send the same search intent to every provider
Each provider received the same company cohort and the same underlying intent: find the current CEO, chief executive, founder, or co-founder.
The tested providers were:
- Apollo
- CompanyEnrich
- Coresignal
- Crustdata
- FullEnrich
- People Data Labs
- Prospeo
Provider interfaces are not identical. Apollo, CompanyEnrich, Crustdata, FullEnrich, and People Data Labs exposed a result-size control in the tested runner, so the benchmark requested up to 100 people per company.
3. Apply one strict title filter
Provider-side title matching varies. To keep the included candidate scope consistent, every runner applied a strict client-side title classifier before candidates entered the comparison.
Qualifying titles included CEO, chief executive, founder, co-founder, and the language variants encoded in the evaluator. Misleading contexts such as former founder, assistant to the CEO, advisor to the founder, or CEO office were excluded from the qualifying title rule.
This benchmark does not attempt to find every executive or decision-maker. It tests a defined CEO and founder scope.
4. Normalize LinkedIn URLs and deduplicate people
LinkedIn person URLs were normalized before evaluation. Query parameters, capitalization, host variations, and trailing path differences were removed. Duplicate URLs were discarded within each provider-company result.
The evaluator then used Harvest person identifiers when available to catch cases where two different LinkedIn URLs represented the same person. Across the published run, 5,661 candidate rows were observed, 13 duplicate-person rows were excluded, and 5,648 candidate rows remained in the metrics.
5. Verify every candidate against HarvestAPI
Every normalized candidate URL was looked up through HarvestAPI. The HarvestAPI quickstart and official SDK repository describe its LinkedIn profile data capabilities.
For this benchmark, HarvestAPI served as the operational verification source for three questions:
- Does the LinkedIn URL resolve to a usable person profile?
- Is the person currently at the target company?
- Does the current role match the accepted CEO or founder title scope?
Current roles came from currentPosition plus experience entries explicitly ending in Present, Current, or Now. Historical roles required an explicit end date. Roles without enough information to establish currentness were kept separate as uncertain rather than forced into correct or stale categories.
Company identity was matched by LinkedIn company URL or identifier first. An exact, unique cohort-company name could be accepted when the saved LinkedIn URL was stale because of a rename or rebrand. Conflicting or non-unique name matches were treated as ambiguous.
6. Assign one candidate verdict
| Verdict | Meaning | Included as correct? |
|---|---|---|
correct | Current qualifying CEO or founder role at the target company | Yes |
stale | Former qualifying role at the target company | No |
wrong_title | Currently at the target company, but not as CEO or founder | No |
wrong_company | Current CEO or founder role at another company | No |
wrong_both | Neither current target employment nor a qualifying current title | No |
ambiguous | Company identity or role currentness cannot be resolved safely | No |
unverified | Harvest profile is missing or empty | No |
The public people table combines wrong title, wrong company, and wrong both into Wrong. It combines ambiguous and unverified into Unresolved. The detailed categories were retained in the benchmark run's scorecard and candidate verdict file, which are not included in the public repository.
7. Calculate company and people outcomes
The headline calculations are:
Company coverage = companies with at least one correct person / 502
People coverage = provider correct person-company pairs / 933 pooled correct pairs
Cost per resolved company = calculated benchmark cost / resolved companies
Cost per correct person = calculated benchmark cost / correct person-company pairs
People coverage is technically pooled recall. The public label is more readable, but the limitation is the same: a real CEO or founder missed by every provider does not appear in the pool.
The evaluator also calculated verified precision, lower-bound precision, F1, Hit@1, Hit@3, Hit@5, mean reciprocal rank, request success, and detailed cost fields. Those supporting files were part of the benchmark run but are not published in the public repository. The metrics are useful for deeper analysis but are not required for the headline comparison.
What to do: When running your own test, freeze the cohort, provider files, verification snapshot, pricing assumptions, and evaluation code together. Changing one component can change the result.
Which Provider Covered the Most Companies?
Company coverage answers a direct account-level question: for what percentage of the 502 target companies did the provider return at least one candidate classified from the Harvest snapshot as a current CEO or founder?
Every percentage below uses the same denominator of 502 companies.
| Provider | Companies resolved | Coverage | No candidates | Results but no correct |
|---|---|---|---|---|
| CompanyEnrich | 442 | 88.0% | 41 | 19 |
| Crustdata | 441 | 87.8% | 51 | 10 |
| Apollo | 417 | 83.1% | 77 | 8 |
| FullEnrich | 411 | 81.9% | 79 | 12 |
| Coresignal | 390 | 77.7% | 105 | 7 |
| People Data Labs | 374 | 74.5% | 116 | 12 |
| Prospeo | 367 | 73.1% | 114 | 21 |
Company coverage takeaway
CompanyEnrich resolved the most companies, but the lead over Crustdata was one company. The two providers were effectively tied on company breadth in this snapshot: 442 resolved companies for CompanyEnrich and 441 for Crustdata.
The failure mix adds context. CompanyEnrich returned no candidates for 41 companies and returned candidates without a correct result for 19. Crustdata had more empty companies, at 51, but fewer companies with only non-correct results, at 10.
Apollo resolved 417 companies, six more than FullEnrich. FullEnrich still found substantially more correct people overall, which means its correct matches were more concentrated within fewer companies. That distinction becomes visible only when company coverage and people coverage are shown separately.
Coresignal, People Data Labs, and Prospeo had larger no-candidate groups. Prospeo also had the highest count of companies where results were returned but no candidate was classified as correct.
What to do: If the workflow needs one usable person for every target account, use company coverage as the primary metric and inspect the two unresolved-company buckets before selecting a provider.
Which Provider Found the Most Correct People?
The people-focused comparison measures Harvest-evaluated person yield. It distinguishes total returned candidates from correct people and shows whether non-correct candidates were stale, wrong, or unresolved.
People coverage uses the 933 pooled correct person-company pairs found by at least one tested provider.
| Provider | Returned | Correct | People coverage | Unique finds | Stale | Wrong | Unresolved |
|---|---|---|---|---|---|---|---|
| Crustdata | 882 | 825 | 88.4% | 5 | 0 | 40 | 17 |
| CompanyEnrich | 898 | 809 | 86.7% | 3 | 27 | 49 | 13 |
| FullEnrich | 864 | 794 | 85.1% | 3 | 7 | 57 | 6 |
| Apollo | 773 | 717 | 76.8% | 15 | 7 | 43 | 6 |
| People Data Labs | 763 | 688 | 73.7% | 8 | 5 | 45 | 25 |
| Coresignal | 712 | 676 | 72.5% | 1 | 5 | 31 | 0 |
| Prospeo | 756 | 642 | 68.8% | 11 | 31 | 65 | 18 |
People coverage takeaway
Crustdata found the most correct people, with 825 pairs classified as correct and 88.4% people coverage. CompanyEnrich followed with 809 correct people and 86.7% coverage. FullEnrich was close behind at 794 correct people and 85.1% coverage.
The returned count matters only in relation to outcomes. CompanyEnrich returned the most included candidates, at 898, but Crustdata converted a slightly smaller candidate set into 16 more correct matches. Coresignal returned the fewest candidates and found fewer correct people, but it also produced the lowest wrong count and no unresolved candidates in this snapshot.
Apollo's 15 unique finds were the highest in the comparison. Prospeo was next with 11, followed by People Data Labs with 8. These values matter for waterfall strategies because they show that a lower-coverage provider can still contribute correct contacts the leading provider missed.
Unique finds are relative to the tested provider set. If another provider enters the benchmark and returns the same person-company pair, the original provider's unique count decreases.
What to do: Use correct count and people coverage when the workflow needs multiple founders or broad contact yield. Use unique finds when evaluating a secondary provider for incremental waterfall coverage.
What Do Stale, Wrong, and Unresolved Results Mean?
A single accuracy percentage hides how a provider fails. This benchmark keeps failure outcomes visible because each type creates a different operational risk.
Stale results
A stale result is someone who formerly held a qualifying CEO or founder role at the target company. Stale profiles are not counted as correct, even when the person remains well known or still mentions the company elsewhere on the profile.
Crustdata returned no stale candidates in the snapshot. People Data Labs and Coresignal each returned 5, FullEnrich and Apollo each returned 7, CompanyEnrich returned 27, and Prospeo returned 31.
Staleness matters most in outbound, routing, and ownership workflows. A former founder may still be relevant for historical research, but that does not make the profile a correct answer to a current-role query.
Wrong results
Wrong combines three decisive error categories:
- Wrong title: the person currently works at the company but is not a CEO or founder.
- Wrong company: the person currently has a qualifying title, but at another company.
- Wrong both: neither the current company nor current title matches.
Coresignal had the lowest wrong count at 31, followed by Crustdata at 40 and Apollo at 43. Prospeo had the highest wrong count at 65. Counts should still be read alongside the total returned and correct counts, because providers produced different candidate volumes.
Unresolved results
Unresolved combines ambiguous and unverified candidates. An ambiguous profile contains some evidence but not enough to determine company identity or role currentness safely. An unverified profile is missing or empty in the Harvest snapshot.
An unresolved candidate is not evidence that the provider is wrong. It is evidence that the benchmark cannot make a decisive determination from its selected verification source. Coresignal had no unresolved candidates in this snapshot. People Data Labs had the most, at 25.
What to do: Match error tolerance to the workflow. Automated outreach should be strict about stale and wrong profiles. Research tools with human review may tolerate more unresolved candidates if they preserve the uncertainty clearly.
How Much Did Each Provider Cost?
The pricing table uses the benchmark's August 28, 2026 price-per-credit snapshot. The rates represent approximately comparable $500 plan tiers and may differ from current public pricing, negotiated contracts, annual discounts, or other usage levels.
| Provider | USD per credit | Cost per resolved company | Cost per correct person |
|---|---|---|---|
| CompanyEnrich | $0.0011 | $0.0049 | $0.0027 |
| Prospeo | $0.0150 | $0.0159 | $0.0091 |
| Crustdata | $0.3000 | $0.0183 | $0.0098 |
| FullEnrich | $0.0500 | $0.0261 | $0.0135 |
| Apollo | $0.0160 | $0.0297 | $0.0173 |
| Coresignal | $0.0140 | $0.2556 | $0.1475 |
| People Data Labs | $0.2800 | $0.6648 | $0.3614 |
Pricing takeaway
CompanyEnrich had the lowest calculated cost per resolved company and correct person. Prospeo and Crustdata were the next-lowest providers by cost per correct person, although their coverage and outcome profiles differed.
The credit inputs do not all have the same evidence status. Crustdata, CompanyEnrich, and FullEnrich usage came from cost fields reported in their benchmark outputs. Prospeo usage came from the runner's estimate. Apollo was estimated at one bulk-match credit per raw enriched person with phone reveal disabled, People Data Labs at one credit per raw returned result, and Coresignal at ten collect credits per collected person.
That makes this a modeled run-cost comparison. It is useful for understanding order-of-magnitude differences under a consistent snapshot, but it is not a substitute for a quote based on your endpoint mix and volume.
What to do: Recalculate the pricing constants using the plan and contract tier you would actually buy. Then compare cost per usable outcome, not cost per nominal API request.
What Did Each Provider Do Well?
No provider led every category. The provider-level picture is more useful when strengths and limitations are tied to the tested task rather than turned into a universal product ranking.
CompanyEnrich
CompanyEnrich resolved the most companies at 442 of 502 and returned 809 correct people. It also had the lowest calculated cost per resolved company and correct person.
The main limitation in this snapshot was stale data within the returned candidate set. CompanyEnrich produced 27 stale profiles, compared with zero for Crustdata and 5 to 7 for several other providers. Its three unique finds were also lower than Apollo, Prospeo, People Data Labs, and Crustdata.
Crustdata
Crustdata found the most correct people at 825 and had the highest people coverage at 88.4%. It resolved 441 companies, one fewer than CompanyEnrich, and returned no stale candidates.
Its calculated cost per correct person was $0.0098, higher than CompanyEnrich and Prospeo but lower than the other four tested providers. Crustdata also contributed five unique finds.
FullEnrich
FullEnrich found 794 correct people, the third-highest total, and reached 85.1% people coverage. It returned seven stale profiles and six unresolved candidates.
Those correct people were spread across 411 companies, fewer than Apollo's 417 despite FullEnrich finding 77 more correct people. FullEnrich therefore looked stronger for multi-person yield than for one-contact-per-company breadth in this cohort.
Apollo
Apollo resolved 417 companies and found 717 correct people. Its clearest differentiator was incremental value: 15 correct person-company pairs were not returned by any other tested provider.
Apollo's people coverage was 76.8%, below Crustdata, CompanyEnrich, and FullEnrich. Its result pattern may still be useful in a waterfall when unique contacts matter more than being the highest-coverage first source.
People Data Labs
People Data Labs found 688 correct people across 374 companies and contributed eight unique finds. It returned only five stale candidates and four wrong-title candidates, but it had 37 wrong-company results and 25 unresolved candidates.
Its calculated unit costs were the highest in this benchmark under the selected price-per-credit assumption. People Data Labs provides flexible query controls through its official Person Search API, so buyers should recalculate cost for the exact query size and contract tier they plan to use.
Coresignal
Coresignal resolved 390 companies and found 676 correct people. It had the lowest wrong count at 31 and no unresolved candidates in the snapshot.
Coresignal's main limitation was breadth. It returned no candidates for 105 companies and reached 72.5% people coverage. Its calculated cost was also higher than five of the other providers under the benchmark assumptions.
Prospeo
Prospeo had the second-lowest calculated cost per correct person and contributed 11 unique finds, the second-highest unique count.
It resolved 367 companies and found 642 correct people, the lowest totals in the tested group. It also had the highest stale count, wrong count, and results-without-a-correct-company count. The benchmark therefore shows a low-cost but lower-coverage tradeoff for this specific task.
What to do: Treat the provider analyses as starting points for your own test. Use the same company list, role definition, verification method, and cost model your production workflow will use.
How Should Buyers Interpret the Benchmark?
The best people search API depends on what the consuming workflow needs. A sales automation system, recruiting product, research database, and human-reviewed search interface may value different outcomes.
| Workflow priority | Start with | Why |
|---|---|---|
| One usable executive per account | Company coverage | Measures whether each target company is resolved |
| Find multiple founders or executives | Correct count and people coverage | Rewards broader person yield classified as correct |
| Add a fallback provider | Unique finds | Measures incremental contacts missed by others |
| Minimize bad CRM records | Stale and wrong counts | Shows decisive quality failures |
| Keep uncertain records reviewable | Unresolved count | Preserves verification uncertainty |
| Control enrichment spend | Cost per resolved company or correct person | Connects spend to usable outcomes |
Do not rank providers by returned volume alone
A provider can increase its returned count by loosening title or company matching. That may create more correct contacts, but it may also create more stale and wrong candidates. Returned volume is an input to interpretation, not a success metric by itself.
Do not rank providers by cleanliness alone
A provider can return a small, conservative set and appear exceptionally clean while missing many companies and people. That is why this benchmark does not use verified precision as the headline people metric. Correct count and people coverage better represent yield classified as correct, while stale, wrong, and unresolved counts keep quality visible.
Separate first-source performance from waterfall value
Company coverage indicates how well a provider can operate as a primary source. Unique finds indicate whether it adds something as a fallback. A provider that is not the best first source can still create meaningful incremental coverage in a multi-provider workflow.
What to do: Decide whether you are choosing one provider or designing a waterfall before reading the rankings. The best first source and best fallback may not be the same API.
What Are the Benchmark's Limitations?
This benchmark documents its method, but it is not universal. The following limitations should stay visible wherever the results are published.
1. CompanyEnrich publishes and participates in the benchmark
This is a self-published CompanyEnrich benchmark, not an independent analyst evaluation. The public repository supports fresh benchmark runs, but the original dataset and result artifacts are not included, so the exact published run cannot be regenerated from the repository alone.
2. People coverage is relative, not absolute
The 933-person pool contains correct pairs found by at least one provider. A real CEO or founder missed by all seven providers is absent. People coverage therefore compares the tested systems against one another and does not estimate total real-world recall.
3. HarvestAPI is an operational source of truth
Harvest gives every candidate the same independent verification path, but it can still contain missing, stale, or structurally ambiguous profiles. The evaluator keeps those cases unresolved rather than assuming the provider is wrong.
4. The cohort represents one market segment
The sample contains active YC companies from selected 2024 batches. Results may differ for local businesses, public companies, older startups, nonprofits, agencies, companies outside major professional networks, or targets in other regions.
5. Provider search interfaces are not identical
Title syntax, company filters, ranking, pagination, result limits, billing, and data models vary. The benchmark standardizes the target intent and downstream filtering, but it cannot make the underlying products identical.
6. The title scope is intentionally narrow
The accepted titles focus on CEOs and founders. The benchmark does not measure broader executive coverage, department heads, managers, recruiters, engineers, or every language-specific title that may matter in other workflows.
7. Pricing is a dated calculation
Rates and credit rules can change. Some usage inputs are reported and others estimated. The published values reflect the benchmark snapshot rather than guaranteed current pricing.
8. The benchmark does not evaluate contactability
The test evaluates LinkedIn person discovery, company match, title match, and role currentness. It does not score email availability, email deliverability, phone coverage, consent, compliance controls, or outreach performance.
9. Results represent one point in time
People change jobs and companies update records continuously. A repeat run can produce different outcomes even when the code and cohort remain fixed.
10. Candidate-level artifacts are intentionally private
The public report contains aggregate statistics only. Names, profile URLs, provider responses, Harvest profiles, screenshots, and candidate-level verdicts are not published because they may contain or permit the inference of personal data and may be subject to source or provider restrictions. This limits independent auditability, but it avoids unnecessary public disclosure of person-level records.
What to do: Run a smaller parallel benchmark on your own target accounts before committing to a provider. Include the exact titles, markets, endpoints, result limits, and downstream verification rules your application requires.
How Can You Run the Benchmark Yourself?
The public benchmark repository provides tooling for collecting fresh provider data and running a new comparison. It does not include the original 502-company cohort, provider responses, Harvest verification records, candidate verdicts, or generated scorecard used for this page. Those artifacts are not published for the reasons described above.
A fresh run should:
- Build and freeze a company cohort.
- Configure API access and record each endpoint, filter, result limit, pagination rule, and retry policy.
- Run the same CEO and founder search intent across the cohort.
- Normalize and deduplicate returned profiles.
- Verify company, title, and currentness through one shared method.
- Generate a scorecard and retain dated inputs and outputs under appropriate access controls.
- Record run timestamps, pricing assumptions, and the exact code commit.
A fresh run requires provider and verification API access and may consume credits. Results may differ because people, company records, endpoints, pricing, and data coverage change over time.
If you publish a fresh benchmark, use synthetic fixtures for public tests and report person-level results only in aggregate. Avoid publishing names, profile URLs, raw responses, screenshots, or row-level hashes derived from person identifiers.
What to do: Use the repository to collect a new dataset and benchmark providers on records you are authorized to process. Preserve dated inputs and outputs under restricted access if you want the run reviewed later.
Frequently Asked Questions
What is a people search API benchmark?
A people search API benchmark compares how different APIs perform on the same person-discovery task and input set. A useful benchmark defines the target roles, normalizes provider results, verifies returned people through one shared method, and publishes both successful and unsuccessful outcomes. This benchmark focuses specifically on finding current CEOs and founders at known companies.
Which provider performed best in this people search API benchmark?
No provider led every dimension. CompanyEnrich resolved the most companies and had the lowest calculated unit cost, while Crustdata found the most correct people and returned no stale candidates. Apollo produced the most unique finds. The best choice therefore depends on whether the workflow prioritizes account coverage, total people found, incremental waterfall value, freshness, or cost.
What does company coverage mean?
Company coverage is the percentage of target companies for which a provider returned at least one candidate classified from the Harvest snapshot as a current CEO or founder. The denominator in this benchmark is all 502 companies. A company is unresolved when the provider returned no candidate or returned candidates without a correct match under that evaluation method.
What does people coverage mean in this benchmark?
People coverage is the number of correct person-company pairs found by a provider divided by the 933 correct pairs found by at least one tested provider. It is a relative comparison among the seven providers, not absolute recall. People missed by every provider are not represented in the denominator.
What counts as a correct person?
A correct person has a current qualifying CEO or founder role at the requested company in the Harvest profile used for verification. The evaluator checks company identity, title, and role currentness. Former founders, current employees with other titles, and founders at other companies are not counted as correct.
What is a unique find?
A unique find is a correct person-company pair returned by exactly one tested provider under the benchmark's Harvest-based evaluation. It indicates incremental value within the current comparison and can help identify useful waterfall providers. The number is not permanent because adding or removing providers can change which pairs remain unique.
Why does the people search API benchmark use HarvestAPI?
HarvestAPI provides a common external profile structure for checking company, title, and currentness across every provider candidate. Using one verification source avoids trusting each provider's own response as proof that the response is correct. Harvest is still imperfect, so missing or ambiguous records are reported as unresolved rather than incorrect.
How were provider costs calculated?
The benchmark multiplied provider credit consumption by a fixed USD-per-credit snapshot from approximately comparable plan tiers. Some providers reported usage in their outputs, while others required documented runner estimates. Cost per resolved company and cost per correct person divide that calculated run cost by the corresponding outcome count.
Is this people search API benchmark independently produced?
No. CompanyEnrich publishes the benchmark and participates in it. The original run data and verification artifacts are not included in the public repository; the repository is for collecting data and running a fresh benchmark. Treat these results as self-published and validate them on your own records.
Can I reproduce the people search API benchmark?
You can use the public repository to collect data and run a fresh benchmark, but you cannot regenerate the exact published comparison from the repository alone because the original dataset and result artifacts are not included.
Why aren't the candidate-level records public?
Candidate-level records may contain or permit the inference of personal data and may be subject to source or provider restrictions. The public report therefore contains aggregate results only. Names, profile URLs, raw provider responses, Harvest profiles, screenshots, and candidate-level verdicts are not published.
Test the APIs on Your Own Records
This benchmark shows how seven providers performed on one defined CEO and founder search task. Your best provider may change with your account segment, geography, role scope, result limit, and pricing tier.
The strongest buying process is a small, reproducible test using your own companies and the fields your workflow actually consumes. If you want to include CompanyEnrich in that test, review the People Search API and run the same queries against your own target accounts.
