Current Employees API Guide
By Kooperativa Engineering
Mapping who works where inside a target account used to require a LinkedIn Sales Navigator seat and a lot of manual scrolling. A current employees endpoint does the same job as an API call: pass a company ID, get back a paginated roster of everyone currently indexed at that company.
What the response actually looks like
The response is intentionally lightweight, name, title, country, profile URL, rather than a full profile per person. Full profiles for a roster this size would be slow and mostly wasted, since most sales and recruiting workflows only need enough to decide who is worth enriching further.
{
"company_id": "2135371",
"employees": [
{
"id": "a1b2c3d4-...",
"full_name": "Patrick Collison",
"current_title": "CEO & Co-founder",
"geo_country_code": "US",
"linkedin_url": "https://www.linkedin.com/in/patrickcollison"
}
],
"total": 16904,
"page": 1,
"per_page": 25,
"pages": 677
}Why the two-step pattern matters at scale
For a company with 16,904 indexed employees, that is 677 pages at 25 per page. Nobody actually wants the full roster hydrated into full profiles up front, that would be tens of thousands of unnecessary full lookups. The pattern that actually works: page through the lightweight list first, filter down by title keywords client-side or by rerunning search scoped to the company, and only bulk-enrich the identifiers you actually care about.
The honest limitation
total here reflects employees indexed in the dataset, not a company's actual headcount as reported anywhere official. For a large, well-documented company like Stripe the two numbers track closely. For a smaller or less LinkedIn-visible company, indexed count can undershoot real headcount meaningfully, which matters if the workflow depends on a complete roster rather than a representative sample.
Get started
Try Kooperativa
One API key. Person and company enrichment, structured search, and monitors under one flat license.