LinkedIn Employee-Count API: Track Headcount Growth as a Buying Signal (2026)

A company that is hiring fast is a company that just raised money, landed customers, or is pushing into a new market. That makes headcount growth one of the cleanest buying signals in B2B — and LinkedIn is where it shows up first, because employees update their own profiles long before a company issues a press release.

This guide shows you how to read that signal programmatically: pull a company's exact employee count and its company size band with one API call, then track the number over time to see who is growing, who is flat, and who is quietly shrinking. No LinkedIn login, no headless browser, no scraping HTML that breaks every month.

I also want to be straight with you about what the number actually is, because most articles on this topic get it wrong. So this is not a generic "call an endpoint" post — it includes real data I pulled on July 2, 2026 from seven well-known companies, a working Python tracker you can run today, and an honest breakdown of where the metric is reliable and where it is a proxy.

The two headcount numbers, and what each one means

Every LinkedIn company page carries two different headcount figures, and Serpent's company API returns both. They look similar. They are not the same thing, and mixing them up is the single most common mistake in this space.

• company_size — the band the company picks for itself, like "5,001-10,000 employees". It is self-reported, coarse, and rarely changes. Good for bucketing accounts into SMB, mid-market, or enterprise.
• employee_count — the number of LinkedIn members who currently list this company as their employer. LinkedIn calls these "associated members". It updates continuously as people join, leave, and edit their profiles. This is the field that moves, so this is the field you track.

Here is the part almost nobody says out loud: employee_count is a proxy, not a payroll number. For a developer-heavy B2B company it tracks real headcount closely. For a giant consumer brand it can run far above true payroll, because huge numbers of people loosely associate themselves with the brand. You will see that clearly in the real data below — and it is exactly why the trend matters more than the absolute value.

Real data: 7 companies, pulled live

To make this concrete rather than hypothetical, I pulled the company endpoint for eight well-known companies on July 2, 2026 and recorded exactly what came back. Seven resolved cleanly; the eighth returned empty because I passed the wrong slug — a useful reminder that the identifier has to match the exact /company/<slug> in the URL. Here is the raw, unedited result:

Method: one live GET /api/linkedin/company?slug=<slug> call per company on 2026-07-02, fields copied verbatim from the JSON responses. Your own pull will differ — that is the point of tracking.

Three things jump out, and each one is a lesson:

1. Airbnb is the proxy problem in one row. Its employee_count reads 70,452, yet its self-reported band is "5,001-10,000 employees". Airbnb's true payroll is in the single-digit thousands — the 70,452 figure is inflated by the enormous number of people who associate with the brand on LinkedIn. Take the absolute number at face value and you would badly mis-size the account. Watch the direction of that number over months, though, and it is still a valid growth signal.

2. The band and the count answer different questions. Microsoft and Shopify both sit in the "10,001+" band, but their counts (233,540 vs 29,034) are an order of magnitude apart. The band tells you the weight class; the count tells you the trajectory.

3. Not every field is always populated. Microsoft and OpenAI came back with no founded_year in this pull. The API returns null for a missing field rather than guessing — so write your code to expect gaps (the tracker below does).

The endpoint: one GET request

There is exactly one endpoint and one required parameter. Pass either the full company URL or the bare slug — both resolve to the same company.

GET https://apiserpent.com/api/linkedin/company?slug=<company-slug>
# or, equivalently:
GET https://apiserpent.com/api/linkedin/company?url=https://www.linkedin.com/company/<company-slug>

Header: X-API-Key: YOUR_API_KEY

A minimal cURL call to confirm your key works:

curl "https://apiserpent.com/api/linkedin/company?slug=stripe" \
  -H "X-API-Key: YOUR_API_KEY"

The response is {"success": true, "data": { ... }}. For a headcount tracker you only need three fields, though the full firmographic object (industry, HQ, specialities, founded year and more) comes back too — see the full company-data guide for the complete field map.

{
  "success": true,
  "data": {
    "universal_name_id": "datadog",
    "name": "Datadog",
    "company_size": "1,001-5,000 employees",
    "employee_count": 9715,
    "founded_year": 2010,
    "industry": "Software Development"
  }
}

The universal_name_id is the stable slug — use it as your primary key when you store snapshots, because display names get rebranded but the slug does not.

From a snapshot to a growth signal

One call gives you a point-in-time reading. A growth signal is the difference between two readings. So the whole technique is: pull on a schedule, store each reading with a date, and diff.

You do not need to poll often. Headcount is a slow-moving metric, so weekly is plenty for a sales-intent or competitive-tracking use case; monthly is fine for market research. Polling daily just burns calls to watch noise. What you are looking for is the multi-week trend: a company adding 8% to its associated-member count over a quarter is in a very different phase than one that has been flat for a year.

The pattern in three steps:

1. Keep a watch-list of company slugs (your target accounts, your competitors, your portfolio).
2. Fetch and append a dated employee_count row for each, on your schedule.
3. Compute the delta against the previous reading and flag anything that crossed a threshold you care about.

A working headcount tracker in Python

Here is a complete, runnable tracker. It reads a watch-list, fetches the current count for each company with retry handling, appends a dated row to a CSV, and prints the change since the last run. It uses only the standard library plus requests, and it expects missing fields (per lesson 3 above).

import csv, os, time, datetime, requests

API_KEY = "YOUR_API_KEY"
BASE = "https://apiserpent.com/api/linkedin/company"
HISTORY = "headcount_history.csv"
WATCHLIST = ["stripe", "datadog", "snowflake", "openai"]  # company slugs

def fetch_count(slug, retries=3):
    """Return (employee_count, company_size) for a slug, or (None, None)."""
    for attempt in range(retries):
        r = requests.get(BASE, headers={"X-API-Key": API_KEY},
                         params={"slug": slug}, timeout=60)
        if r.status_code == 429:                      # rate limited
            time.sleep(int(r.headers.get("Retry-After", 5)))
            continue
        if r.status_code == 503:                      # transiently busy
            time.sleep(2 ** attempt)
            continue
        if r.status_code == 404:
            return None, None
        r.raise_for_status()
        d = r.json().get("data", {})
        return d.get("employee_count"), d.get("company_size")
    return None, None

def last_reading(slug):
    """Most recent employee_count we saved for this slug, or None."""
    if not os.path.exists(HISTORY):
        return None
    prev = None
    with open(HISTORY) as f:
        for row in csv.DictReader(f):
            if row["slug"] == slug and row["employee_count"]:
                prev = int(row["employee_count"])
    return prev

def run():
    today = datetime.date.today().isoformat()
    new_file = not os.path.exists(HISTORY)
    with open(HISTORY, "a", newline="") as f:
        w = csv.writer(f)
        if new_file:
            w.writerow(["date", "slug", "employee_count", "company_size"])
        for slug in WATCHLIST:
            prev = last_reading(slug)
            count, band = fetch_count(slug)
            w.writerow([today, slug, count if count is not None else "", band or ""])
            if count is None:
                print(f"{slug:12} no data (check the slug)")
            elif prev:
                delta = count - prev
                pct = 100 * delta / prev
                arrow = "up" if delta > 0 else "down" if delta < 0 else "flat"
                print(f"{slug:12} {count:>8,}  {arrow} {delta:+,} ({pct:+.1f}% since last run)")
            else:
                print(f"{slug:12} {count:>8,}  (baseline saved)")
            time.sleep(0.3)   # gentle pacing; tune to your rate bracket

if __name__ == "__main__":
    run()

The first run writes a baseline. Every run after that prints something like stripe 15,924 up +412 (+2.7% since last run). Point it at your target accounts, drop it in a weekly cron job or a scheduled GitHub Action, and you have a hiring-momentum feed for the cost of a few API calls. Because a missing company becomes a flagged row instead of a crash, you can leave it running unattended.

What headcount growth actually tells you

The number is a means, not an end. Here are the four questions a headcount trend answers better than almost any other public signal.

1. Sales and buying intent

Rapid hiring almost always follows funding or revenue growth, and both mean new budget. A target account that added double-digit percentage headcount in a quarter is a warmer account than one that has been flat — and you learned it before their next funding announcement. Pair the count with the LinkedIn jobs endpoint to see which teams are growing, which tells you which buyer to approach.

2. Competitive intelligence

Track your competitors' counts weekly and you get a free early-warning system. A rival quietly growing its engineering headcount is investing in product; one that is shrinking may be in trouble or refocusing. None of this is in a press release — it is in the trend line you are already collecting.

3. Investment and market research

For anyone screening companies, headcount velocity is a standard proxy for momentum. A watch-list of a sector's players, sampled monthly, surfaces the ones accelerating and the ones stalling — a cheap first-pass filter before deeper diligence.

4. Account scoring and ABM

Combine employee_count trend with the static company_size band and industry to score accounts: a mid-market software company growing headcount 20% year over year is a different priority than a same-size company that is flat. Feed the delta into your lead score as a recency-weighted signal.

Honest limits: where the number is a proxy

I would rather you trust this data because you know its edges than be surprised later. So here is where employee_count is solid and where it is not:

• It is associated members, not payroll. As Airbnb showed, consumer brands read high. Use it as a relative, trend-over-time signal, not an HR-grade absolute.
• It lags real hiring slightly. A new hire appears in the count when they update their own profile, which can be days or weeks after they start. Fine for a weekly trend; not a real-time feed.
• Small and brand-new companies are sparse. A ten-person startup may have a handful of associated members and a noisy count. The signal is strongest for companies with a real LinkedIn presence.
• Some fields can be null. As the real data showed, founded_year and other fields are occasionally absent. Code defensively.

For how LinkedIn itself defines the associated-member figure and company size, LinkedIn's own Company Pages help documentation is the primary source worth reading. Everything the API returns comes from the public company page — nothing private, nothing behind a login.

Errors, rate limits and retries

The endpoint uses neutral, predictable status codes so your tracker's logic stays simple:

Your rate limit is per-account and scales with your balance bracket, so the way to run bigger watch-lists faster is to keep a working balance rather than to hammer one key. The tracker already handles each code correctly; the only knob you usually tune is the inter-request sleep. Full semantics are in the API docs.

Pricing

Company is the richest LinkedIn dataset, priced accordingly — but it is pay-as-you-go with no subscription and no per-seat fee.

Do the math on a real tracker: 200 companies pulled weekly is 10,400 calls a year — about $31 a year on Default, $3.12 on Growth, or $1.56 at Scale. The same deposit unlocks the discount across every endpoint, not just company. See the full pricing page for the other LinkedIn datasets and the SERP APIs.

A note on compliance

Serpent's company endpoint accesses publicly available LinkedIn data only. There is no login, password, cookie, or credential in the flow — you send a public company URL and your Serpent key, and nothing else. That keeps the integration clean, but it does not make every use automatically permitted.

Whether your specific use is allowed depends on LinkedIn's terms, your jurisdiction, and how you store and apply the data. Tracking public company headcount for B2B research is a common, well-trodden use case, but treat compliance as your own decision rather than something this article waves through. The API only ever touches public data and never authenticates as a user; you remain responsible for lawful use.

FAQ

What is the difference between employee_count and company_size?

company_size is the headcount band a company selects for its own LinkedIn page (for example "1,001-5,000 employees"). employee_count is the number of LinkedIn members who list that company as their employer — LinkedIn's "associated members" figure. The band is stable and self-reported; the count is live and moves as people add or update where they work. For big consumer brands the count can run well above true payroll headcount. Track the trend in employee_count, not the absolute number.

How do I track LinkedIn headcount growth over time?

Call the company endpoint on a schedule (weekly is plenty for most signals), store each response with a timestamp, and compare successive snapshots. The API returns a point-in-time reading, so the time series is something you build by saving snapshots. The Python tracker in this guide fetches employee_count for a watch-list, writes a dated row per company, and computes the change since the last run.

Is LinkedIn employee count accurate?

It is accurate as a reading of LinkedIn's associated-member count on the day you pull it, which is what LinkedIn itself displays. It is a proxy for headcount, not an audited payroll figure: it lags real hiring slightly, and for consumer brands it overstates payroll. That is why the growth trend is the useful signal — the direction and rate of change are meaningful even when the absolute number is a proxy.

How much does the LinkedIn company API cost?

Company data is $3.00 per 1,000 requests on Default. A single $100 deposit unlocks Growth at 10× off ($0.30/1,000) and a single $500 deposit unlocks Scale at 20× off ($0.15/1,000). Tracking 200 companies weekly is about 10,400 calls a year — roughly $31/year on Default and $1.56 at Scale. LinkedIn endpoints are pay-as-you-go with no subscription.

Do I need a LinkedIn login to use the employee-count API?

No. You send a public company URL or slug and your Serpent API key in an X-API-Key header. The company endpoint accesses publicly available LinkedIn data only — there is no LinkedIn login, cookie, or OAuth flow on your side. You remain responsible for using the data lawfully and within LinkedIn's terms.