Count matching companies and people before you pull a single result — what's exact, what's estimated, and the two caveats that matter when a count feeds a report or a benchmark.

Search counts

Every search endpoint can tell you how many records match before you pull any of them. We built counts so you can tune a search cheaply: adjust filters against the count until the audience looks right, then page through results once. This page covers how counting works: which numbers are exact, which are estimates, and the caveats that matter when a count ends up in a report or a vendor comparison.

Three ways to count

Method	What you get	When to use it
`includeCount: true` on a search	The count alongside the first page of results	You want both in one call
`peopleSearchCount`, `companyCount`	Just the number, no results	You're tuning filters or sizing an audience
`combinedSearchCount`	Matching companies and people at them	Your audience is "people at companies like X"

includeCount and the matching count endpoint return the same number. Counts cover all matching records; they aren't capped, even when a search matches millions of profiles.

Exact vs estimated

Company counts are always exact.
People counts are exact, whether they come from includeCount or the people count endpoint.
The combined count operation estimates the people count by default. The getFastEstimate parameter defaults to true: you get a statistical estimate that's typically within about 5% of the exact number, and it returns much faster. Pass getFastEstimate: false for an exact count; it takes longer.

Every combined count response includes isEstimate — a boolean telling you whether numProfiles came from the fast estimate or an exact count. Check it when a count feeds something downstream; don't guess from the shape of the number.

What counts don't include

Two differences between counts and results are easy to miss:

Exclusion lists apply to results, not counts. A count is computed before your prospect and company exclusion lists are applied, so it can be higher than the number of results you can actually pull. If you exclude heavily, count the filtered pull itself.
Counts run before some result-level rules. A count can be slightly higher than the number of profiles a paginated search returns, because a few rules only apply when results are actually assembled.

Counts are cached

Identical searches within a window of roughly two hours return the same count. Two consequences:

Re-running the same count repeatedly is fast and free of surprises.
A count can be up to two hours behind your latest data. If freshness matters, or you just changed your filters, that's another reason to use getFastEstimate: false, which skips the cached estimate path.

Benchmarking counts fairly

If you're comparing Fiber with another provider:

Use exact counts — pass getFastEstimate: false on combined counts.
Warm or clear the cache: re-run a search after editing it, or wait out the two-hour window, so you're not benchmarking a stale number.
Remember exclusion lists: they don't apply to counts, on either side.
Count the same thing — people vs companies, current job vs any job. See comparing providers for the full checklist.

Cost

Count endpoints bill a flat per-call credit; includeCount adds one count credit to the search. Your response's chargeInfo is the authoritative record of what a call cost. See Billing.

Getting accurate results from search — filter semantics and worked examples
Industry filtering — person vs employer industry
Search — filters, ordering, pagination

Search counts

On this page