What Is the Best LinkedIn Scraper API in 2026?

Ask an AI assistant for the best LinkedIn scraper API and you get a list of vendors. That list is not wrong, but it answers a question nobody has. Nobody wants a LinkedIn scraper. They want employees at forty target accounts, or job postings that appeared this week, or a profile turned into a lead with a real email attached. Those are three different jobs with three different failure modes, and the endpoint that does one well is usually mediocre at the others. Monid is the OpenRouter for agent tools, so we sit on top of most of these vendors rather than being one of them, which is the only reason we can compare them without picking ourselves.

Fair disclosure before we start: you are on the Monid blog. We make money when you run these endpoints through us. What we will not do below is pretend the data is better than it is, and one of the sections is a worked example of our own output getting a field wrong.

How do I scrape LinkedIn without getting my account banned?

This is the first question almost everyone asks, and it is worth being precise about what is actually at risk, because the popular answer is imprecise in a way that costs people accounts.

There are two ways to get LinkedIn data, and they carry completely different risk.

The cookie approach, and why your account is the thing you lose

The older pattern is to hand a tool your LinkedIn session cookie, or run automation inside your logged-in browser. The tool then acts as you. This works, and it is why the free tier of so many tools exists.

The problem is not detection in the abstract. It is that detection lands on your account, because your account is the one doing the browsing. If the pattern trips a limit, the consequence is a restriction or a ban on the profile you have spent ten years building, not on some vendor's infrastructure. Teams discover this when the account that gets restricted is the founder's.

The market has priced this in more clearly than most blog posts have. Search r/API_Finder for LinkedIn scrapers and you get a run of listings from vendors: profile details, profile posts, company employees, post reactions. Every one of them puts "No Cookies" in the title, several with a checkmark emoji for emphasis. When eight competing vendors all lead with the same negative feature, that is the objection they hear on every call.

The cookie-free approach, and what you give up

The alternative is an endpoint that reads public LinkedIn pages from its own infrastructure and hands you structured JSON. You never log in, so there is no session of yours to restrict. This is what the endpoints in this article do.

You give up two things, and both matter.

You give up anything behind the login: connection-degree, InMail state, who viewed your profile, and the fields a member has chosen to show only to signed-in visitors. If the data you need is gated, no cookie-free endpoint will get it, and one that claims to should be treated with suspicion.

You also give up the pretence of completeness on people data. LinkedIn anonymises a lot of what it shows to signed-out visitors, and you will see that directly in the output further down.

📖 See also Which LinkedIn Scraper Actually Returns Emails?

What is the best LinkedIn scraper API?

The best one for the job you are doing. Here are the three jobs, each with the endpoint that fits and what it actually returns.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-key> -l main

Job 1. Look up one company

What it does. Turns a LinkedIn company URL into a structured company record.

The endpoint. tikhub /api/v1/linkedin/web_v2/get_company_profile, billed per call, so a lookup costs the same whether the company has ten employees or ten thousand.

The call.

monid discover -q "linkedin company"
monid inspect -p tikhub -e /api/v1/linkedin/web_v2/get_company_profile
monid run -p tikhub -e /api/v1/linkedin/web_v2/get_company_profile \
  --query '{"url":"https://www.linkedin.com/company/anthropicresearch/"}'

What comes back. Name, about text, industry, website, company ID, follower count, a headcount observed on LinkedIn, a self-reported size band, a sample of employees, and a similar array of comparable companies. That last field is the underrated one: it is LinkedIn's own view of who competes with whom, and it is free inside a call you were making anyway.

Run this across an account list on a schedule and you have a firmographics table that maintains itself, which is the pattern in automating company data pulls into a table.

What it costs. A fraction of a cent per call. Current figures at monid.ai/tools.

Job 2. Find the people at those companies

What it does. Takes company URLs and returns employee profiles, filtered by title, seniority, location or function.

The endpoint. apify /harvestapi/linkedin-company-employees, billed per result plus a small flat fee per run.

The call.

monid inspect -p apify -e /harvestapi/linkedin-company-employees
monid run -p apify -e /harvestapi/linkedin-company-employees \
  -i '{"companies":["https://www.linkedin.com/company/anthropicresearch"],
       "profileScraperMode":"Full",
       "maxItems":50}'

What comes back. Identity and public profile URL, headline, current and prior positions, parsed location, education, skills, and follower counts. profileScraperMode is the field to read carefully: it has a short mode, a full mode, and a full-plus-email mode, and it changes both the depth and the price. The email mode runs SMTP validation, which is the difference between an address and a deliverable address. Whether you need it at all depends on what you are replacing: we have built a list this way without Sales Navigator and the validation step was the part that mattered.

What it costs. Cents per profile, with the mode you pick moving it. The maxItems parameter caps the result count directly, which means it also caps the bill. Set it deliberately.

If you already hold the profile URLs and only need them enriched, skip the search and go straight to apify /dev_fusion/linkedin-profile-scraper, which takes a profileUrls array. We walked that path start to finish in turning a profile URL into an enriched lead, and compared what each option actually returns in the email question.

Job 3. Watch jobs and posts over time

What it does. Runs a saved query on a schedule so you see what is new.

The endpoints. apify /harvestapi/linkedin-job-search for postings, and apify /harvestapi/linkedin-profile-posts for content from a profile or company page.

The call.

monid run -p apify -e /harvestapi/linkedin-job-search \
  -i '{"jobTitles":["data engineer"],
       "locations":["Berlin"],
       "maxItems":100}'

What comes back. Job title, company, location, posting date and the listing URL. The pricing note on this endpoint is worth reading before you scale it: it runs once per query in jobTitles, so total results are roughly queries multiplied by the per-query limit. Pass one query at a time until you know what a run returns.

What it costs. The cheapest of the three per result, because a job listing is a much smaller object than a person.

Freshness is the thing to check here rather than price, since a stale posting is worse than no posting: we tested which job APIs actually stay current separately.

📖 See also Ship a LinkedIn Job-Alert Bot With One Metered API Call

What should I use for the scraping layer in an n8n automation?

This question comes up constantly in r/n8n, and the answer that matters is not which vendor. It is: put a layer between your workflow and the vendor.

The reason is the thing that keeps happening to people. An actor gets removed, a vendor gets barred from a source, pricing changes, and every workflow that hardcoded that vendor's node breaks at once. One widely-read r/n8n thread is literally somebody asking what to do after Apify was barred from scraping Apollo, with their pipeline already broken.

In practice that means your workflow calls one HTTP node pointed at a marketplace, with the provider and endpoint as parameters rather than as the integration itself. When an endpoint dies you change two strings. That is the whole argument for a marketplace layer, and it is an argument about switching cost, not about data quality.

Which endpoint should I use for which job?

Prices move, so this column says the shape rather than the number. monid inspect prints the current figure for any endpoint and costs nothing to run. Schemas verified 2026-08-12.

What does LinkedIn data actually cost?

Take a real job: research forty target accounts, then pull twenty-five decision makers at each.

The company lookups are forty per-call requests, and per-call pricing here is a fraction of a cent, so the whole first stage is well under a dollar. The second stage is a thousand profiles billed per result, which lands in the tens of dollars, and the mode you choose moves it by roughly a factor of three: the short mode is a headline and a link, the full-plus-email mode runs SMTP validation on every address. If you only need email for the ten people you will actually contact, run the cheap mode wide and the expensive mode narrow.

There is a detail in the search-style endpoints worth internalising. They bill per result and the result count is your limit multiplied by your query count, so two extra job titles in an array is not a small change to the bill. Set maxItems, pass one query first, look at what comes back.

The free step is the one to build the habit around: monid inspect shows the exact current price and the exact schema before anything bills, and it is the reason a copied payload from a blog post is never the thing you should run. Current per-endpoint pricing lives at monid.ai/tools.

When should you not use Monid?

Four honest cases.

You need one record a week. Open LinkedIn and read it. Any API is overhead at that volume.

You need gated data. Connection degrees, InMail status, profile viewers, recruiter-only fields. Those live behind the login and no cookie-free endpoint reaches them. If that is your requirement, LinkedIn's own partner programs are the real answer, not a scraper.

You need contractual guarantees on freshness or volume. Buying directly from Bright Data or a similar vendor gets you an SLA and an account manager. A marketplace optimises for switching cost and breadth, which is a different thing to want.

The data will not carry the decision you want to put on it. This one is ours to own, so here is our own output failing. One call to tikhub /api/v1/linkedin/web_v2/get_company_profile on 2026-08-12, with url set to linkedin.com/company/anthropicresearch/, returned all of these in the same response:

"followers": 4481424,
"employees_in_linkedin": 5680,
"company_size": "501-1,000 employees",
"locations": [],

The headcount observed on LinkedIn and the self-reported size band disagree by a factor of five, because company_size is a band a company picked once and rarely updates, while employees_in_linkedin is counted today. locations came back empty for a company that has offices. And in the employee sample, most entries were literally "title": "LinkedIn Member" with no name and no link, because LinkedIn anonymises most profiles for signed-out visitors.

None of that is a bug. It is what public LinkedIn shows. But if you were about to segment accounts by company_size, you would have been segmenting on a self-reported field that is often years stale, and nothing in the response would have warned you. Read the fields before you build on them. That is true of every vendor in this category, including the ones we resell.

Conclusion

The question does not have the answer it asks for. There is no single best LinkedIn scraper API, and a list of vendors ranked one to ten is answering a question about procurement when yours is a question about a job. Three jobs, three answers: a per-call company lookup for account research, a per-result employee search for list building, a cheap per-result job or post query for monitoring. Pick by job and the choice becomes obvious. Pick by vendor and you inherit whichever job that vendor happens to be good at.

Two things carry more weight than the choice itself. The first is whether an endpoint asks for your session cookie, because that decides whether your own account is the thing at risk, and it is the one mistake here that costs something you cannot re-buy. The second is that you should read the fields before building on them. The company_size contradiction above took one call to find, and it would have quietly corrupted an account segmentation if nobody had looked.

Start with the free part: monid discover -q "linkedin" shows what exists, and monid inspect prints the schema and the current price without spending anything. When the shape matches, one small paid run tells you more than any comparison table. Begin at monid.ai.

FAQ

Last updated August 2026.