LinkedIn Profile Pro

Deep, cookie-free LinkedIn profile scraper. Hand it profile URLs (or bare slugs), get back full profile metadata plus recent posts plus published articles — in a single call, in one dataset row per profile.

Built for Clay, n8n, and Make pipelines where you currently have to call two or three separate actors to assemble the same picture.

---

What you get per profile

{
  "url": "https://www.linkedin.com/in/williamhgates/",
  "slug": "williamhgates",
  "name": "Bill Gates",
  "headline": "Creator, Top Voice",
  "about": "Co-chair of the Bill & Melinda Gates Foundation...",
  "photoUrl": "https://media.licdn.com/...",
  "country": "US",
  "city": "Seattle, Washington, United States",
  "followers": 40000000,
  "connections": 8,

  "workHistory": [
    { "company": "Gates Foundation", "companyLinkedInUrl": "...",
      "title": null, "description": null, "location": null,
      "startDate": "2000", "endDate": null, "isCurrent": true },
    { "company": "Breakthrough Energy", "startDate": "2015", "isCurrent": true, ... },
    { "company": "Microsoft", "startDate": "1975", "isCurrent": true, ... }
  ],
  "education": [
    { "school": "Harvard University", "startYear": 1973, "endYear": 1975 }
  ],
  "languages": [],
  "awards": [],
  "externalLinks": [],

  "recentPosts": [
    { "urn": "7464707901635395584",
      "url": "https://www.linkedin.com/posts/williamhgates_...",
      "text": "I felt so powerless and scared when my dad was diagnosed with Alzheimer's...",
      "postedAt": "2026-05-25T03:10:26.346Z",
      "likes": 1765, "comments": 84, "shares": null,
      "isArticle": false, "headline": null }
    // up to ~10 recent posts per profile
  ],
  "publishedArticles": [
    { "url": "https://www.linkedin.com/pulse/every-year-2-million-...",
      "title": "Every year, 2 million babies are stillborn.",
      "datePublished": "2026-05-02T00:35:55.000+00:00",
      "description": "A simple retinal scanner can change that." }
    // up to ~10 articles per profile (when published)
  ],

  "fetchedAt": "2026-05-26T15:20:00.000Z",
  "source": {
    "htmlSize": 613470,
    "proxyGroup": "DATACENTER",
    "attemptsRequired": 1,
    "uaUsed": "facebookexternalhit"
  }
}

---

Input

Field	Type	Default	Notes
profileUrls	string[]	required	Full LinkedIn URLs or bare slugs. Both work. https://uk.linkedin.com/in/... URLs accepted. /company/, /jobs/, non-LinkedIn URLs rejected silently. ID-style URLs (/in/ACoAAA…) are not usable — see ID-style profile URLs below.
includeRecentPosts	boolean	true	Extract up to ~10 recent posts per profile. Bundled in same charge.
includeArticles	boolean	true	Extract LinkedIn-published articles. Bundled in same charge.
enrichEngagementFromDom	boolean	true	Parse comment + share counts (post likes already come from JSON-LD). Negligible cost.
postedAfter	string	—	Drop posts/articles older than this date. Accepts YYYY-MM-DD or full ISO 8601 timestamp. Leave empty for no lower bound.
postedBefore	string	—	Drop posts/articles newer than this date. Same format as postedAfter. Pair both for a between-range filter. Undated items are dropped when any date filter is active.
maxRetriesPerProfile	integer	5	Fresh-IP attempts per profile. 1-10.
useResidentialFallback	boolean	false	After 3 datacenter failures, retry via Apify residential proxy. Boosts success ~70% → ~85%. Adds ~$5/1K cost on stubborn profiles only.
concurrency	integer	5	Parallel profile fetches. 1-20.
maxItems	integer	500	Hard cap on profiles processed.
proxyConfiguration	object	Apify datacenter BUYPROXIES94952	Override only if you have a specific reason — datacenter is the validated optimum (cheaper AND higher success rate than residential for this surface).

---

Pricing

$0.004 per profile resolved. That's it. Recent posts and articles bundled — no per-post charge.

• Your first 10 resolved profiles are FREE — a one-time allowance for your account so you can trial the actor before paying. It does not reset on each run; once you've used the 10, every resolved profile is charged. The run log always tells you how many free profiles you have left.
• No charge for invalid slugs, soft-blocks, or empty responses.
• No charge for ID-style URLs (/in/ACoAAA…), which cannot be resolved without a login.
• No charge for duplicate inputs — we dedupe upfront, including the Sales Navigator and public forms of the same person.
• Charge only fires when a Person JSON-LD block has been successfully parsed.

Compare with the alternative on the Store: profile scraper at $4/1K + profile-posts at $2/1K = $6/1K bundled. This one is $4/1K bundled, in one call, one dataset row, one charge.

---

How it works (high-level)

LinkedIn whitelists social-link-preview bots (facebookexternalhit/1.1, Twitterbot/1.0) and serves them rich server-rendered HTML with structured JSON-LD blocks: Person, DiscussionForumPosting, Article. We fetch each profile with that UA via Apify's datacenter proxy, parse the JSON-LD, augment with DOM-extracted engagement counts (comments, shares), and emit a normalized row.

When a profile resists datacenter IPs (rotating residential block-lists land on Apify's pool), the optional residential fallback kicks in after 3 failures. Soft-block detection is byte-precise (LinkedIn's "we noticed unusual activity" template is exactly 317,547 bytes), so we never mistake it for a real 200.

No cookies, no login, no LinkedIn account, no Voyager API impersonation. Public data only.

---

Why some profiles fail to resolve

If a profile fails, the warning log tells you exactly why:

Reason in log	What it means	Can retries / residential fallback fix it?
profile_not_found	The slug genuinely doesn't exist on LinkedIn. Probably a typo or the profile was deleted/renamed.	No — check spelling.
not_publicly_visible	The slug exists but the owner has disabled public-profile visibility. You can see this profile if you're logged into LinkedIn, but our cookie-free path cannot.	No — this is a LinkedIn privacy setting, not anti-bot. Common for recruiters, executives, and privacy-conscious users.
soft_block	LinkedIn anti-bot fired (the 317KB "unusual activity" template).	Yes — usually clears with useResidentialFallback: true or higher maxRetriesPerProfile.
fetch_errors	Network errors before reaching LinkedIn (proxy / DNS).	Yes — retry or try a different proxy group.
no_person_jsonld	Page returned content but no Person JSON-LD shape we recognize (likely a new LinkedIn rendering variant).	Worth reporting — please open an issue with the slug.
id_url_requires_login	You passed an ID-style URL (/in/ACoAAA…). The ID is probably valid and the profile probably public — LinkedIn just won't resolve ID URLs for anonymous visitors.	No — convert it to a vanity URL first. See below.

No charge fires for any failed profile.

---

ID-style profile URLs (/in/ACoAAA…)

LinkedIn has two profile URL forms:

Form	Example	Works here?
Vanity	linkedin.com/in/williamhgates	✅ Yes
ID (a.k.a. fsd_profile / miniProfile)	linkedin.com/in/ACoAAAJHE7sB5OxuKHuzguZ9L6lfDHqw--cdnJg	❌ No

ID URLs are what LinkedIn search, Sales Navigator, and Recruiter emit, so they show up a lot in CRM exports. Unfortunately LinkedIn resolves them only for authenticated sessions. Requesting one as an anonymous visitor returns the "Profile Not Found" page even when the profile is fully public — verified against known-live IDs across every guest-reachable render path (/in/, /pub/dir/, /public-profile/in/, /mwlite/in/, /m/in/, country subdomains) and four user agents; /profile/view?id=… redirects to /uas/login. The ID→profile mapping simply lives behind the login wall, so no cookie-free scraper can resolve an ID URL — this is a LinkedIn access-control boundary, not an anti-bot measure that retries or residential proxies can get around.

What the actor does about it: it detects ID-style inputs, preserves their casing (IDs are case-sensitive, unlike vanity slugs), warns you up front with a count, and fails them as id_url_requires_login with an explanation instead of a misleading "check your spelling". You are never charged for them.

The two ID shapes you'll see map to LinkedIn's two identifier namespaces — ACoAAA… is a flagship profile (urn:li:fsd_profile), ACwAAA… is a Sales Navigator profile (urn:li:fs_salesProfile). Neither resolves anonymously.

What the actor can tell you about an ID (free, no charge)

These IDs are not opaque hashes. The actor decodes them offline and reports LinkedIn's numeric member ID, which is identical across both namespaces for the same person:

ACw AAAZOcggB zpEjfkM3etdMvVrQzrxKfPBTfOA  ┐
ACo AAAZOcggB pSKg3gBQ8n8-JTBe1wfM31CMnBY  ┘ both → member 105804296

Two practical uses:

• De-duplicate a mixed export. If your list contains both the Sales Navigator and flagship ID for one person, the actor now recognises them as the same target and processes them once instead of twice.
• A stable join key. The member ID is a durable identifier for a person even when their vanity URL changes.

What it does not give you is the vanity slug. The remaining bytes are a keyed signature, so one ID form cannot be converted into the other, and every numeric-ID URL (/profile/view?id=…, /in/<number>) is dead or redirects to the login wall. There is no cookie-free route from an ID to a profile — only the workarounds below.

If your IDs start with ACw (Sales Navigator) — you probably already have what you need

Sales Navigator lead records carry the public profile URL alongside the internal ID. Mainstream SalesNav scrapers return both — e.g. publicUrl (https://www.linkedin.com/in/deepakpshukla) and publicId (deepakpshukla) right next to profileId (ACwAAAJHCyYB…). One such scraper's docs even warn: "Use publicUrl for the correct public profile link. profileUrl is built from the Sales Navigator ID and may not match the vanity URL."

So this is usually an export-column problem, not a missing-data problem: pull publicUrl / publicId / publicProfileUrl rather than profileId / profileUrl, and everything works with no ID conversion anywhere in your pipeline. The actor detects ACw IDs and says so in the run log.

For flagship (ACo…) IDs: open the URL in a browser where you're signed in to LinkedIn. LinkedIn redirects to the person's vanity URL (/in/their-name) — copy that and pass it here.

If you specifically need ID-URL input, this actor is the wrong tool

Some paid services do resolve both ID shapes. They aren't using the public surface to do it — their output includes verified emails, exact connection/follower counts, certifications and courses, none of which appear in LinkedIn's cookie-free structured data. That implies authenticated LinkedIn sessions or a licensed dataset behind the scenes. Note that "no cookie" in a product title usually means you don't supply cookies, not that no authenticated session exists anywhere in the chain.

That's a real trade-off, not a trick this actor could copy: resolving ID URLs means giving up the no-authentication guarantee that makes this one cheap, legally clean, and free of account-ban risk. If ID input matters more to you than that guarantee, use one of those services — you'll get a better result than fighting this limitation.

---

Common use cases

• Clay/n8n/Make enrichment pipelines — pipe a list of LinkedIn URLs in, get full profiles + recent activity out.
• B2B prospecting with context — beyond just name+title, see what they've posted recently to personalize outreach.
• Investor / hedge fund headcount tracking — re-run periodically, diff workHistory[].isCurrent to detect hires and exits.
• Competitive intel on key people — track posts + articles to monitor what competitors' execs are talking about.
• Recruiting research — surface candidates' recent activity, not just their static resume.

---

What's NOT included (cookie-free limits)

• Skills, certifications, volunteer, recommendations — these sections aren't in the cookie-free JSON-LD. Add them in v0.2 if there's demand (DOM-extractable).
• Per-reaction breakdown (like vs love vs celebrate) — only total likes available.
• Comment thread bodies — only comment counts (auth-walled bodies).
• Sales Navigator, Recruiter, full activity history — separate auth-scope, out of scope.
• Per-position job titles — for some profiles LinkedIn doesn't include per-worksFor titles in the JSON-LD. You'll see title: null even when the company is present. Profile-side limitation.

Expect ~95% success rate on public profiles at default settings; ~98% with useResidentialFallback: true. The remaining tail is profiles where the owner has set Public profile to off (cookie-free fundamentally cannot reach those — see the failure-reason table above) or new LinkedIn rendering variants we haven't taught the extractor about yet. Failed profiles are NOT charged.

Heads up on "partial-public" profiles: some profile owners enable the master "Public profile" switch but disable per-section visibility (Experience, Education, Summary, etc.) in their LinkedIn privacy settings. The actor will resolve these profiles and charge $0.004 because we extract whatever LinkedIn ships — but the row may have a redacted last name (e.g. "Dianne E."), an empty about, mostly-empty workHistory entries, and few/no posts. There is no cookie-free way around per-section privacy. If your input list includes many such profiles, factor it into your cost expectation.

---

License

MIT — use the data within LinkedIn's Terms of Service and applicable scraping law (hiQ v. LinkedIn covers public data; this actor never touches authenticated surfaces).