Ultimate Guide to LinkedIn Company API in 2026, With Full Python Code Samples

If you're trying to figure out how to use the LinkedIn Company API in 2026, here’s the blunt answer up front: the official route is still possible, but it is gated, limited, and usually a poor fit unless you are already inside LinkedIn’s partner ecosystem. If you just need company data in code, there are faster ways to get productive.

I’ve spent enough years around company data to know that the hard part is rarely the HTTP request. The hard part is access, reliability, freshness, and whether the thing still works once legal, product, and pricing realities show up.

This guide is for developers who want the real answer. Not the doc-page answer.

We’ll cover:

• how the official LinkedIn Company API works
• what you can realistically get access to
• full Python code samples for the official route
• where the official route breaks down
• what to use instead if your actual goal is company intelligence in production

Let’s start with the official path.

Why trust this guide?

I’ve built and sold products in this category. I’ve paid for APIs that looked clean in the docs and turned into a support problem a month later. I’ve also built around those problems.

That matters here because most articles about the LinkedIn Company API stop at "here is the endpoint" and skip the part that actually burns engineering time.

My bias is simple: I care about what ships.

Two LinkedIn API paths

There are really two buckets here:

1. The official LinkedIn Company API
2. Third-party company data APIs

If you specifically need LinkedIn-native workflows, partner access, or product-approved use inside LinkedIn’s ecosystem, the first bucket matters.

If you just want company data in code, the second bucket usually matters more.

The official LinkedIn Company API

The official LinkedIn Company API is not fake. It exists. It can be useful. But it is not an open, self-serve developer product in the way Stripe or Twilio trained people to expect.

That distinction matters.

What the LinkedIn Company API gives you

At a high level, the official LinkedIn Company API can expose:

1. Company profile data
2. company name
3. website
4. industry
5. company size
6. locations

7. founded year

8. Follower and page metrics

9. follower count

10. selected audience or page analytics, depending on scope

11. Posts and updates

12. company posts

13. engagement metrics in some partner contexts

14. Jobs and related org data

15. current openings or related organization data, depending on product access

That all sounds reasonable. The issue is that the phrase "can expose" is doing a lot of work.

Who the LinkedIn Company API is for

Here’s the practical use-case map.

User Group	Use Cases
Developers	internal research tools, CRM enrichment, company search features
Data teams	firmographic analysis, account scoring, segmentation
Recruiting teams	employer research, hiring-spike detection, company tracking
Sales teams	account research, territory planning, target account enrichment
Consultants	market maps, partner research, category analysis
Founders	competitor tracking, early market validation, account intelligence

The mistake I see is people assuming the official API is automatically the best option for all of those. It isn’t.

Access is the real product

This is the part most LinkedIn Company API articles soften up. I won’t.

The API itself is not the main obstacle. Access is.

Four things to know first

1. It is gated

2. You are often applying for product access, not just generating keys.

3. Approval can be slow

4. Expect forms, review, use-case scrutiny, and back-and-forth.

5. Competitive products have a harder time

6. If your product starts looking too much like something LinkedIn already sells, that is not helpful.

7. Pricing and packaging are not especially transparent

8. This is not a clean public pricing page kind of experience.

That does not mean "don’t use it." It means go in sober.

Step 1: Apply as a LinkedIn Partner

If you want the official LinkedIn Company API, this is usually where the journey starts.

Pick your lane

LinkedIn’s partner ecosystem generally maps to categories like:

• Talent Solutions
• Marketing Solutions
• Sales Navigator Application Development
• LinkedIn Learning Integration

Pick the one that actually fits what you do. Do not try to be clever here.

Prepare the application properly

You want to be concrete about:

• what product you are building
• how you use LinkedIn data
• why your use case belongs in LinkedIn’s ecosystem
• how your product complements rather than collides with LinkedIn

Vague applications die in review.

Submit it

The current place to start is LinkedIn’s product catalog:

https://developer.linkedin.com/product-catalog

Then wait.

That is not me being dramatic. That is just the process.

Step 2: Set up a LinkedIn developer app

While you are waiting, you can at least get your app plumbing done.

Basic setup flow

1. Go to https://developer.linkedin.com/
2. Create or sign into your developer account
3. Create an app
4. Associate and verify the app with your company
5. Request the relevant product access
6. Retrieve your Client ID and Client Secret if approved

Be specific in the app description. LinkedIn tends to reward specificity.

Step 3: Use the LinkedIn Company API with Python

Now for the part you came for.

I’ll show the official approach first.

The moving parts

You will typically deal with:

1. Company Search API
2. OAuth 2.0
3. LinkedIn access scopes and permissions

Get an access token

import requests

LINKEDIN_CLIENT_ID = 'your_client_id'
LINKEDIN_CLIENT_SECRET = 'your_client_secret'


def get_access_token():
    """
    Exchange LinkedIn app credentials for an access token.
    """
    token_url = 'https://www.linkedin.com/oauth/v2/accessToken'

    payload = {
        'grant_type': 'client_credentials',
        'client_id': LINKEDIN_CLIENT_ID,
        'client_secret': LINKEDIN_CLIENT_SECRET,
    }

    headers = {
        'Content-Type': 'application/x-www-form-urlencoded'
    }

    response = requests.post(token_url, headers=headers, data=payload, timeout=30)

    if response.status_code == 200:
        return response.json().get('access_token')

    print(f"Token error {response.status_code}: {response.text}")
    return None

Store the token securely and reuse it until it expires. Nothing fancy required.

Search for companies

import requests
from urllib.parse import urlencode


def search_companies(access_token, search_query='LinkedIn Corporation', filters=None):
    """
    Search for companies on LinkedIn.
    """
    base_url = 'https://api.linkedin.com/v2/companySearch'
    params = {
        'q': 'search',
        'query': search_query,
        'projection': '(elements*(entity~(id,name,localizedName,vanityName,logoV2,locations)),paging)'
    }

    if filters:
        for key, value in filters.items():
            if isinstance(value, list):
                for i, v in enumerate(value):
                    params[f'filter.{key}[{i}]'] = v
            else:
                params[f'filter.{key}'] = value

    headers = {
        'Authorization': f'Bearer {access_token}',
        'X-Restli-Protocol-Version': '2.0.0'
    }

    url = f"{base_url}?{urlencode(params)}"
    response = requests.get(url, headers=headers, timeout=30)

    if response.status_code == 200:
        return response.json()

    print(f"Search error {response.status_code}: {response.text}")
    return None

Full runnable Python example

import requests
from urllib.parse import urlencode

LINKEDIN_CLIENT_ID = 'your_client_id'
LINKEDIN_CLIENT_SECRET = 'your_client_secret'


def get_access_token():
    token_url = 'https://www.linkedin.com/oauth/v2/accessToken'
    payload = {
        'grant_type': 'client_credentials',
        'client_id': LINKEDIN_CLIENT_ID,
        'client_secret': LINKEDIN_CLIENT_SECRET,
    }
    headers = {'Content-Type': 'application/x-www-form-urlencoded'}
    response = requests.post(token_url, headers=headers, data=payload, timeout=30)

    if response.status_code == 200:
        return response.json().get('access_token')

    print(f"Token error {response.status_code}: {response.text}")
    return None


def search_companies(access_token, search_query='Stripe', filters=None):
    base_url = 'https://api.linkedin.com/v2/companySearch'
    params = {
        'q': 'search',
        'query': search_query,
        'projection': '(elements*(entity~(id,name,localizedName,vanityName,logoV2,locations)),paging)'
    }

    if filters:
        for key, value in filters.items():
            if isinstance(value, list):
                for i, v in enumerate(value):
                    params[f'filter.{key}[{i}]'] = v
            else:
                params[f'filter.{key}'] = value

    headers = {
        'Authorization': f'Bearer {access_token}',
        'X-Restli-Protocol-Version': '2.0.0'
    }

    url = f"{base_url}?{urlencode(params)}"
    response = requests.get(url, headers=headers, timeout=30)

    if response.status_code == 200:
        return response.json()

    print(f"Search error {response.status_code}: {response.text}")
    return None


if __name__ == '__main__':
    token = get_access_token()
    if token:
        result = search_companies(token, search_query='Stripe')
        print(result)

A few practical notes:

• input is generally case-insensitive
• Boolean behavior is not what many users expect
• one-company-at-a-time workflows are more reliable than trying to get fancy
• respect rate limits or you’ll waste time debugging your own traffic patterns

Where the LinkedIn Company API breaks

This is where the official LinkedIn Company API starts to feel less like a developer tool and more like a negotiated relationship.

1. Rate limits

Even generous-looking limits stop feeling generous when you need to:

• refresh thousands of accounts
• run nightly enrichment jobs
• support customer-triggered lookups
• reprocess stale records

A demo workload is not a production workload. I’ve learned that one the expensive way.

2. Limited company context

For many real use cases, LinkedIn company data is too narrow on its own.

You may need:

• funding history
• executive data
• better address coverage
• broader company-web signals
• unified account identifiers outside LinkedIn URLs

That is usually where teams start bolting on more sources.

3. Dependency risk

This is the strategic issue.

If your product depends on access you do not truly control, then your roadmap is partially rented. That is fine if the business case supports it. It is not fine if you are pretending otherwise.

Proxycurl, then NinjaPear

This is the right place for the update.

Historically, Proxycurl existed because a lot of developers wanted LinkedIn-style company and people data without the official LinkedIn Company API friction. That was the whole appeal: faster onboarding, simpler auth, and practical data access.

That part was real.

The 2026 update is that Proxycurl has been sunset. I’m the founder behind Proxycurl, and the work has since moved to NinjaPear.

I’m keeping the Proxycurl context in this guide because the implementation lessons still hold, and a lot of developers still search for Proxycurl by name. But if you are reading this in 2026 and asking what to use now, the answer is not Proxycurl. It is NinjaPear.

A better 2026 alternative

If what you actually need is company data in code, I would look at Company API first.

More specifically, I’d start with the Company Details Endpoint.

Why? Because it takes a company website as the primary input, which is a much better key for most modern workflows than a LinkedIn company URL.

That sounds small. It is not small.

Your CRM has websites. Your warehouse has domains. Your outbound list probably has domains. Your product likely does not want to anchor itself to LinkedIn URLs if it can avoid it.

What NinjaPear Company API returns

With the Company Details Endpoint, you can retrieve data such as:

• company name
• company type
• founded year
• industry
• employee count
• executive data
• office addresses
• public social links
• public listing details where available

And beyond company details, the same API family includes:

• website lookup
• employee count
• company updates
• funding data
• free logo lookup

That last part matters because most company enrichment jobs do not stop at "give me the company name and headcount."

They turn into:

• enrich the CRM
• score accounts by size and funding
• monitor target accounts
• build competitor maps
• feed a prospecting workflow

Quick Python example with NinjaPear

This is the cleanest version of the job most people actually want done.

import requests

NP_API_KEY = 'YOUR_API_KEY'


def fetch_company_details(website: str):
    api_endpoint = 'https://nubela.co/api/v1/company/details'
    headers = {
        'Authorization': f'Bearer {NP_API_KEY}'
    }
    params = {
        'website': website
    }

    response = requests.get(api_endpoint, headers=headers, params=params, timeout=30)

    if response.status_code == 200:
        return response.json()

    print(f"Error {response.status_code}: {response.text}")
    return None


if __name__ == '__main__':
    company = fetch_company_details('https://stripe.com')
    if company:
        print('Name:', company.get('name'))
        print('Founded year:', company.get('founded_year'))
        print('Employee count:', company.get('employee_count'))
        print('Executives:', company.get('executives'))
        print('Addresses:', company.get('addresses'))

If you also want funding data:

import requests

NP_API_KEY = 'YOUR_API_KEY'


def fetch_company_funding(website: str):
    api_endpoint = 'https://nubela.co/api/v1/company/funding'
    headers = {
        'Authorization': f'Bearer {NP_API_KEY}'
    }
    params = {
        'website': website
    }

    response = requests.get(api_endpoint, headers=headers, params=params, timeout=30)

    if response.status_code == 200:
        return response.json()

    print(f"Error {response.status_code}: {response.text}")
    return None


if __name__ == '__main__':
    funding = fetch_company_funding('https://stripe.com')
    if funding:
        print('Total funds raised USD:', funding.get('total_funds_raised_usd'))
        print('Funding rounds:', funding.get('funding_rounds'))

Short. Useful. No partner application.

Spent way too long getting LinkedIn data into my agent using scrapers. DOM changes at the worst times, captchas hit at random hours. Finally moved to an API endpoint. Haven't thought about it since. Using https://t.co/Rh1qtIzrZs - profile data and company lookups through a single HTTP call.

— Millo the first (@millo_2_assist) Mon May 18 04:02:11 +0000 2026

LinkedIn Company API vs alternatives

If you are comparing 3 or more options, don’t do it with marketing adjectives. Do it with tradeoffs.

API / Option	Data Quality	Pricing Clarity	Ease of Use	API Surface	Business Reliability	Avg. Score
Official LinkedIn Company API	⭐⭐⭐⭐☆	⭐⭐☆☆☆	⭐⭐☆☆☆	⭐⭐⭐☆☆	⭐⭐⭐⭐☆	3.00/5
Legacy Proxycurl Company API	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐☆☆☆	3.60/5
NinjaPear Company API	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	4.40/5

And here is the more practical comparison.

Feature	LinkedIn API	Legacy Proxycurl	NinjaPear
Primary input	LinkedIn entity / approved API flows	LinkedIn URL	Company website
Getting started	Approval-heavy	Immediate, historically	Immediate
Auth model	OAuth + approval	API key	API key
Funding data	Limited / indirect	Partial in some workflows	Yes, dedicated endpoint
Employee count	Available with constraints	Yes	Yes
Company updates	Partial / product-dependent	Limited by product mix	Yes, dedicated endpoint
Logo endpoint	Not standalone-friendly	Historically available	Yes, free
Non-LinkedIn dependency	No	No	Yes

That final row matters more than most people think.

Compliance and operating model

I’m not going to turn this into a legal essay.

But I will say this plainly: I am much more interested now in products with a cleaner long-term operating model than I was a few years ago.

That is one reason the website-first model matters.

If your goal is company intelligence, building around public web company data is a cleaner foundation than forcing every workflow through LinkedIn-native identifiers.

Beyond company details

If your workflow goes past simple enrichment, NinjaPear already has adjacent tools that fit naturally here.

Relevant products include:

• Monitor API
• Prospector
• Company Logo API
• employee and company enrichment primitives on the same platform

That is useful because production workflows tend to grow sideways.

You start with one endpoint. Then you want monitoring. Then scoring. Then outreach data. Then competitor tracking.

That is how these systems actually evolve.

Final verdict

If you need the official LinkedIn Company API because your product must work inside LinkedIn’s ecosystem, then yes, pursue partner access and build carefully around its limits.

If what you actually want is company intelligence in production, I would not start there.

I would start with a website-first model and test Company API, especially the Company Details Endpoint. It is a simpler input, it gives you broader company context, and it avoids a lot of the partner-program friction that makes the official LinkedIn Company API slow to operationalize.

That is the practical answer in 2026.

If you want the next step, run two or three of your own target accounts through both approaches and compare the payloads you get back. Do that before you commit quarters of engineering time. It will tell you very quickly whether you need the official LinkedIn Company API, or whether you just need usable company data and fewer headaches.