How to Scrape LinkedIn Without Getting Your Account Banned

Copy this line to your agent to read a public profile without touching your account.

set up https://monid.ai/SKILL.md and use tikhub linkedin get_user_profile with just a URL

The question contains the answer once you notice that "scraping LinkedIn" describes two completely different activities. One drives your logged-in browser session and puts your account at risk every time it runs. The other reads a public page and never touches your account at all. On 2026-09-03, three endpoints returned profile data from nothing but a URL, and not one of them has a field for a session cookie. This guide runs through Monid, the OpenRouter for agent tools.

What actually gets a LinkedIn account restricted?

Activity attributable to your account. That is the whole rule, and it explains every case.

The things that carry real risk

Browser automation on your session. Chrome extensions and desktop tools that click through pages while logged in as you. Every request carries your identity, the pacing is inhuman, and the pattern is exactly what automated-activity detection is built to find.

Volume of outbound actions. Connection requests, messages, profile views and endorsements at a rate a person could not sustain. This is the most common trigger by a distance, and it is about outbound actions rather than reading.

Handing your credentials to a third party. Any tool asking for your password or your li_at cookie is going to act as you, from their infrastructure, at their pace. You inherit every consequence.

A low acceptance rate. Sending many connection requests that get ignored or marked "I don't know this person" is a quality signal, and it accumulates against the account rather than the campaign.

The thing that does not

Reading a public profile page from a server that has never logged in as you. There is no account to attribute the request to. Whatever else that is, it is not a way to get your account restricted.

Why the distinction gets lost

Because both are called scraping and the tools sit in the same category page. Somebody who got restricted by an outreach automation tool and somebody who called a profile endpoint report the same activity in a forum post, and the advice that results treats them as one risk.

📖 See also The Best LinkedIn Scraper API in 2026

Why does handing over your li_at cookie put the account at risk?

Because that cookie is your session. Giving it away is giving away the ability to be you.

What the cookie is

li_at is the authentication token in your browser after you log in. Anything holding it can make requests LinkedIn attributes to your account, from any machine, without your password and without triggering a login notification.

What that means operationally

The requests come from the vendor's servers, so the IP and device fingerprint do not match your usual pattern, and the volume matches their scheduler rather than your behaviour. From LinkedIn's perspective your account is now being used in a way that looks nothing like a person and quite a lot like a compromised session.

And what you cannot control

The vendor's pacing, their other customers on the same infrastructure, and how long they keep the token. A cookie is valid until it expires or you log out everywhere, which for most people is months.

The alternative, measured

None of the three profile endpoints checked on 2026-09-03 has any concept of your session:

They read public pages from their own infrastructure. Your account is not involved, so it cannot be restricted for it.

A note on how that table was built, because it nearly went wrong. An automated check flagged the second row as requiring a cookie. Reading the actual sentence showed the opposite: the documentation says "without cookies or proxies". A pattern match on the word produced precisely the wrong claim about a named vendor, which is a good argument for reading the line before publishing the finding.

How do you get profile data without an account?

Three steps. Discovery is free.

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-api-key> -l main

Step 1. Read a profile from its URL

What it does. Returns the profile without any authentication of yours.

The endpoints. tikhub LinkedIn profile lookup, billed per call. Takes url and nothing else.

The call.

monid run -p tikhub -e /api/v1/linkedin/web_v2/get_user_profile --query '{"url": "https://www.linkedin.com/in/<slug>/"}'

What comes back. On 2026-09-03, for a well-known public profile: id, name, city, country_code, position, about, and a posts array where each entry carries a title, a link, created_at and an interaction summary. That last part is worth noting, because recent posts are usually what an outreach researcher actually wanted.

What it costs. Around a cent per call. Current figures at monid.ai/tools.

Step 2. Search when you do not have the URL

What it does. Finds people by attributes instead of by link.

The endpoints. apify/harvestapi/linkedin-profile-search-by-name, billed per result. Its parameters are firstName, lastName, strictSearch, locations, currentCompanies, pastCompanies, schools, currentJobTitles, industryIds, maxPages and maxItems.

What comes back. Matching profiles. strictSearch matters more than it looks: name search without it returns plausible near-matches, and enriching the wrong person is worse than finding nobody.

What it costs. Per result, so bound maxItems before a batch.

Step 3. Keep the account out of the loop entirely

What it does. The actual protection.

The call. No endpoint, a policy:

Data collection  -> API routes, no session, no browser extension
Outreach         -> your account, human pacing, human volume

Keeping these separate is the whole safety model. The risk lives in the second line, and it is a function of how many connection requests and messages you send, not of how much data you read. Mixing them, by letting a tool both collect and send from your logged-in session, is what produces the restriction stories.

📖 See also Proxycurl Shut Down: LinkedIn Data Alternatives

What can you not get this way?

The honest limits, because a route that avoids account risk also avoids account access.

Anything behind the login

Profiles restricted to signed-in viewers, degrees of connection, mutual connections and "who viewed your profile" are all session-scoped. No cookie-free route returns them, because they do not exist without an authenticated identity to compute them against.

Sales Navigator data

Lead lists, saved searches, InMail and Navigator-only filters are a paid product tied to a seat. If your workflow depends on them, it depends on an account, and the safety question becomes how that account is operated rather than which API you call.

Email addresses

LinkedIn does not publish them, so no profile endpoint returns one. Getting from a profile to a contactable address is a separate enrichment step against a different source, covered in which LinkedIn scraper returns emails.

Guaranteed completeness

Public profile data is what the person chose to make public, and it varies enormously. A profile with no about section is not a failed call. Assert on a field that must be present, such as the name, rather than on the response arriving, which is the same discipline as an endpoint returning a full field list and no values.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-09-03. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.

Two routes for the same job is deliberate here rather than padding. LinkedIn data providers have a demonstrated habit of disappearing, and having a second endpoint whose schema you have already read is the cheap insurance described in not depending on one vendor.

Is any of this allowed?

Three things need separating, and most discussion collapses them.

Account risk. Addressed above, and it is the one you fully control. Do not let anything automate your session and your account is not exposed.

LinkedIn's terms. Automated collection is prohibited by the user agreement, and that applies to third-party collection of public pages too. Using an API route removes the account risk; it does not make the activity contractually permitted, and anyone telling you otherwise is selling something.

The law. Publicly accessible data has been treated differently from access requiring authentication in US case law, and the position varies by jurisdiction and continues to move. Data protection law applies separately to what you do with personal data once you hold it, which for EU or UK residents means a lawful basis and a real response to deletion requests. Is web scraping legal in 2026 goes through this properly, and none of it is legal advice.

And the disclosure: this is Monid's blog and we sell per-call access to the endpoints above. The article's central claim, that a cookie-free route cannot get your account restricted, is narrow and true. It is not a claim that the activity is permitted, and we have deliberately not made the broader one.

Conclusion

The ban risk is not in the reading, it is in the account. Tools that drive your logged-in session, hold your li_at cookie, or send outbound actions at machine pace are what produce restrictions. All three profile endpoints measured on 2026-09-03 take a URL and have no parameter for your session at all, so there is nothing for LinkedIn to attribute to you.

So split the workflow: collect through API routes that never authenticate as you, and keep your account for outreach at human volume. That single separation removes almost all of the account risk people are asking about.

What it does not remove is that automated collection breaches LinkedIn's terms regardless of how it is done, and that data protection obligations attach to the personal data once you hold it. Those are real and separate from your account's safety, and worth deciding about deliberately rather than by default.

Free next step: run monid discover -q "linkedin profile data by url" and read the parameter lists. If a tool you are currently using asks for your cookie and these do not, that is the comparison the whole question turns on. Start at monid.ai.

FAQ

Last updated September 2026.