LinkedIn Company or Profile API? Start With the Entity You Need

Start with the question your team needs to answer. A company record describes an organization: industry, size, headquarters and website when public. A profile record describes a person: headline, location and work history when public. Picking the wrong entity can leave you paying for plausible data that cannot fill your report.

I founded Serpent API, whose company and profile endpoints are discussed here. The field and price comparison comes from public documentation reviewed October 1, 2026. The request and output examples are illustrative, not a live delivery comparison.

A company and a person can share a LinkedIn page link in your CRM, but they answer different questions. Start with the record that fits the decision: account facts for a company, contact identity for a person, and deeper profile details only when those details change the outcome. Serpent API offers separate Company, Basic Profile and Full Profile endpoints, so you can keep that choice explicit and avoid paying for detail you do not need. The comparison below also covers official LinkedIn access and other data vendors using their public documentation, checked October 1, 2026. The broader provider guide is the next stop if you are choosing a vendor rather than a record type.

Choose a company or profile API by the question you need answered

Rule of thumb: store companies and people as separate entities. Join them through a company URL or another verified identifier, and record when the relationship was observed. A headline like “former VP at ExampleCo” is not a current employment assertion. A company name is also not a unique key: subsidiaries, renamed firms and lookalike pages can share words.

Fields returned by company and profile APIs

Company takes a LinkedIn company URL or slug. Its stable object includes identity fields, name, tagline and description; website and industry; specialities, size band and employee count; follower count, founding year and company type; an HQ object; and logo URL when public. A company page may omit some of these. The Company API documentation lists the request parameters. For practical extraction details, see the company data guide and what employee count means. LinkedIn-associated employee count is a public platform signal, not audited payroll.

Basic Profile accepts a public profile URL or username. It returns a consistent person object with identity, headline, occupation, location, current company, public experience and education arrays, and other public fields when available. The Profile docs call it best-effort: the shape stays stable, while field depth varies with what the person publishes and what can be read on that call. Two optional field groups add company details or public-web enrichment; each adds 20% to the base call rate. A nested current_company.name is useful context, but it is not a full company record.

Full Profile returns the same person-object shape, aiming to fill richer public summary, experience, education, image and count fields. It can still be sparse. It does not promise a complete résumé or private data; see the Full Profile contract. If your workflow only needs a name and current role, buying Full Profile for every lead creates extra spend and more personal data to manage without improving that decision.

“Same object shape” matters when you later upgrade a basic profile to Full Profile: code can read the same keys. It does not mean every key is filled in every record. Nulls and empty arrays mean unknown or absent from the accessible public page, depending on the field; they are not proof that a person has no education, that a company has no employees, or that a relationship never existed.

A two-stage workflow that avoids unnecessary person lookups

1. Normalize the input. For known accounts, store the full company URL or vanity slug. Keep the source URL and your internal account ID. Do not treat a bare company name as a unique record.
2. Read and validate the company. Check success, that data is an object, and that name and profile_url identify the company you intended. Inspect the fields your targeting rule actually needs; a nonempty object alone is not enough.
3. Score at the account level. Use industry, size band, location and website as signals. Keep unknown values separate from disqualifying values. Store a retrieval timestamp and preserve the original record for later comparison.
4. Look up selected people. Once an account qualifies, request a Basic Profile for each known contact URL. Confirm the name/profile URL and compare its current_company.linkedin_url to the verified company URL. Use a review queue when that link is missing or differs.
5. Add depth only on demand. Use Full Profile when a concrete decision needs public experience or education. Review that information with the person for high-stakes decisions; public pages can be outdated or incomplete.

The alternative for one named person is include_company_details=true on Basic Profile. At Serpent's published rate it costs 1.2 basic units when the group applies; it can save a second request if the person's current company is the only firmographic context you need. For an account list, direct Company calls keep the organization record independent of which employees happen to have public profiles. See the lead-enrichment walkthrough for a complementary implementation and account-fit scoring ideas.

A runnable request pattern and illustrative parsed output

Here is a small Python example for a company URL and one public person profile. It uses the documented GET parameters and X-API-Key header. Set SERPENT_API_KEY in your environment and install requests. The script checks the returned entity before printing a join decision. It does not claim that an HTTP 200 alone gives a usable record.

import os
import requests

BASE = "https://apiserpent.com/api/linkedin"
KEY = os.environ["SERPENT_API_KEY"]


def read_entity(path, params, identity_field):
    response = requests.get(
        BASE + path, params=params,
        headers={"X-API-Key": KEY}, timeout=60,
    )
    response.raise_for_status()
    payload = response.json()
    data = payload.get("data")
    if payload.get("success") is not True or not isinstance(data, dict):
        raise ValueError(f"No usable {path} object")
    if not isinstance(data.get(identity_field), str) or not data[identity_field]:
        raise ValueError(f"Missing {identity_field} in {path}")
    return data


company = read_entity(
    "/company", {"slug": "example-organization"}, "name"
)
profile = read_entity(
    "/profile", {"username": "example-person"}, "full_name"
)

account_url = company.get("profile_url")
current = profile.get("current_company") or {}
person_company_url = current.get("linkedin_url")
joined = bool(account_url and person_company_url
              and account_url.rstrip("/").lower()
                  == person_company_url.rstrip("/").lower())

print({
    "company": company["name"],
    "industry": company.get("industry"),
    "employee_count": company.get("employee_count"),
    "person": profile["full_name"],
    "title": current.get("title"),
    "company_url_match": joined,
    "join_status": "matched" if joined else "review",
})

Illustrative output, not a live response from those placeholder identities:

{
  "company": "Example Organization",
  "industry": "Software Development",
  "employee_count": 420,
  "person": "Alex Example",
  "title": "Operations Director",
  "company_url_match": true,
  "join_status": "matched"
}

Illustrative complete response shapes: These fictional values demonstrate every current field in the Company and person objects. They are examples of the documented contract, not actual API observations or a claim that those fields will be populated for a real record. A basic profile and Full Profile use the same person keys; Full Profile may fill more of them.

Company response

{
  "success": true,
  "data": {
    "linkedin_internal_id": null,
    "universal_name_id": "example-organization",
    "profile_url": "https://www.linkedin.com/company/example-organization",
    "confidence": "high",
    "requested_slug": null,
    "name": "Example Organization",
    "tagline": "Tools for growing teams",
    "description": "Illustrative company description.",
    "website": "https://example.org",
    "industry": "Software Development",
    "specialities": [
      "Workflow software"
    ],
    "company_size": "201-500 employees",
    "employee_count": 420,
    "follower_count": 3100,
    "founded_year": 2014,
    "company_type": "Privately Held",
    "hq": {
      "country": "US",
      "city": "Austin",
      "state": "Texas",
      "postal_code": null,
      "line_1": null
    },
    "locations": [],
    "logo_url": null,
    "background_cover_image_url": null,
    "funding_data": []
  }
}

Basic Profile response

{
  "success": true,
  "data": {
    "public_identifier": "example-person",
    "profile_url": "https://www.linkedin.com/in/example-person",
    "linkedin_internal_id": null,
    "first_name": "Alex",
    "last_name": "Example",
    "full_name": "Alex Example",
    "profile_pic_url": null,
    "background_cover_image_url": null,
    "headline": "Operations Director at Example Organization",
    "occupation": "Operations Director at Example Organization",
    "summary": null,
    "location": {
      "city": "Austin",
      "state": "Texas",
      "country": "US",
      "country_full_name": "United States",
      "full": "Austin, Texas"
    },
    "follower_count": null,
    "connections": null,
    "flags": {
      "open_to_work": null,
      "hiring": null,
      "premium": null,
      "influencer": null,
      "verified": null,
      "top_voice": null
    },
    "current_company": {
      "name": "Example Organization",
      "company_id": null,
      "linkedin_url": "https://www.linkedin.com/company/example-organization",
      "title": "Operations Director"
    },
    "experiences": [
      {
        "title": "Operations Director",
        "company": "Example Organization",
        "company_linkedin_url": "https://www.linkedin.com/company/example-organization",
        "location": null,
        "description": null,
        "starts_at": null,
        "ends_at": null,
        "duration": null
      }
    ],
    "education": [],
    "skills": [],
    "languages": [],
    "honors_awards": [],
    "recommendations": [],
    "people_also_viewed": [],
    "industry": null,
    "member_of": [],
    "websites": [],
    "company_details": null
  }
}

For a production join, normalize LinkedIn URL host and trailing slash, preserve the original URLs, and review redirects or changed company slugs rather than silently assuming equality. The code above is intentionally conservative: a false URL match means review, not “does not work there.” If a response is incomplete, keep that observation separate from a prior good snapshot. For a larger pipeline, persist one row per observation with input URL, returned URL, retrieval time and the fields used in your decision.

Compare company, basic profile and full profile prices

Serpent's published LinkedIn prices, checked October 1, 2026, are per 1,000 calls: Basic Profile $0.50 Default / $0.45 Growth / $0.35 Scale; Company and Full Profile each $1.00 / $0.90 / $0.70. Growth and Scale prices follow qualifying one-time deposits of $100 and $500; the current live balance determines standard request-limit brackets. A deposit is prepaid credit, not a monthly subscription. The company lookup cost worksheet goes deeper on recurring account jobs and usable capacity.

Method: multiply each call count by its Default per-call rate; the last row is $10 + $1. These are usage illustrations, not a monthly invoice, a field-completeness guarantee, or a measured delivery rate. The optional company-details charge follows its documented field-group rules. A direct company call and an enriched person call do not necessarily return identical company fields; sample both against your own required-field checklist.

How other LinkedIn data options compare

There are meaningful alternatives, but their entities and permissions differ. The vendors' linked pages were checked on October 1, 2026. Where a source quotes credits, records or subscription allowances, the table keeps that unit visible instead of pretending it is the same as one Serpent lookup. No simultaneous delivery benchmark was run for this article.

Fair-comparison method: the rows describe the published product as sold, not interchangeable output. Official LinkedIn is about authorized member or organization use. Coresignal and PDL aggregate multiple sources; a record can differ from a LinkedIn page by design. Bright Data prices delivered records, Serpent prices calls, and the cited Apify actor charges for delivered matches/results. Review minimum spend, permissions, field provenance, and whether a failed or partial record consumes a unit before making a procurement decision. Official LinkedIn access is the better fit for an authorized member integration. When you already have public LinkedIn URLs and need inexpensive, best-effort account or contact context, Serpent is a simpler fit to test first.

A practitioner discussion about testing six enrichment APIs on the same companies illustrates a sensible buying habit: inspect matches and required fields on your own sample. It is one user's experience, not a general delivery rate or evidence for vendor prices. The table uses the vendors' own pages for prices and capability claims.

Missing fields, privacy and hard cases

Sparse company page: A company can have a name and URL but omit founded year, headquarters or website. Save the usable fields, mark the rest unknown and decide whether the record satisfies your application. Do not turn a null employee count into zero. A size band and an associated-member count also answer different questions; see the headcount guide.

Sparse profile: A person may hide details, use an unusual name, have an empty experience list or change their vanity URL. Full Profile is an attempt at greater public depth, not a guarantee. A connections count can be an approximation; do not use it as an exact qualification threshold. A returned current_company object may have null fields, so treat a missing company URL as a review item rather than inferring unemployment.

Identity collisions: A company name can match several pages, and a person name is not unique. If you start with a name rather than a known person URL, use the Profile Search candidate list and review the result before enriching. Preserve both requested and returned URLs. In a CRM, keep company and person IDs separate and log any manual resolution.

Time and compliance: Both entities change. Employee count, role and company association are observations from a date, not permanent truths. Public person data still involves privacy obligations. Define a legitimate purpose, minimize fields, restrict access and retention, and consult counsel for sensitive or large-scale use. The legal and terms overview is background, not legal advice. For recruiting, do not make a consequential decision solely from an incomplete public profile; ask the person to confirm.

A practical acceptance test before scaling

1. Pick a small, representative sample of known company URLs and consented or otherwise appropriately handled person URLs, including subsidiaries, renamed firms and sparse profiles.
2. Define required fields for each decision: for example, a verified company identity plus industry for account routing, or a verified person URL plus current title for contact context.
3. Count usable records and missing critical fields by entity. Do not count HTTP 200 as a pass. Compare the returned data with what a person can see on the corresponding public page on the same date.
4. Run the same sample through shortlisted products. Record billed units, cash commitments, latency, duplicate matches, and what their terms permit. Repeat after changes to your source population.

This article does not include a four-vendor field-quality study. The published prices above support a budget estimate; only your sampled parsed results can establish fit for your use case. For tracking a known account list, the recurring company lookup worksheet adds scheduling and capacity math.

FAQ

Should I use a LinkedIn company API or profile API for account research?

Use company data for account facts such as industry, size band, employee count, headquarters and website. Use a person profile for name, headline, location and current role. Add Full Profile only when public experience or education history is essential. A person record does not replace a company record.

Can I get company information from a person profile call?

The basic Serpent Profile response has a current_company object with a name, LinkedIn URL and title when available. An optional include_company_details=true field group can add company firmographics at a 20 percent surcharge, but it is best-effort. A direct company lookup is clearer when the company itself is your primary entity.

What happens when a LinkedIn field is missing?

A missing scalar arrives as null and a missing list as an empty array in the Serpent data object. Treat both as unknown, not as zero, false or evidence that a person has no history. Check the company or profile identity before storing a record, and preserve the raw observation date.

How do the three Serpent LinkedIn endpoint prices compare?

On the Default tier, basic Profile costs $0.50 per 1,000 calls while Company and Full Profile each cost $1.00 per 1,000. Growth rates are $0.45 and $0.90; Scale rates are $0.35 and $0.70. Optional Profile field groups each add 20 percent to that Profile call. Qualifying one-time deposits determine price tier; current balance determines standard rate-limit bracket.

Is an official LinkedIn API interchangeable with public-data lookups?

No. LinkedIn official APIs use OAuth, permissions and product access for authorized member or organization use. The official Profile API concerns the consenting authenticated member; organization fields and access depend on permissions. For approved app management, use official APIs. Public-data lookup services answer a different workflow and still require lawful use of personal data.