What "No Cookies Required" Actually Means for a LinkedIn Scraper

You give it a list of LinkedIn profile URLs (or just usernames). It hands back, per profile: full name, headline, current location, the "about" text, and complete work + education history — job title, company, and dates for every role; school, degree, and dates for every entry.

One profile in, this is what comes out:

{
  "public_identifier": "williamhgates",
  "name": "Bill Gates",
  "headline": "Co-chair, Gates Foundation",
  "location": "Seattle, Washington, United States",
  "about": "...",
  "experience": [
    {"title": "Co-chair", "company": "Gates Foundation", "dates": "2000 - Present"}
  ],
  "education": [
    {"school": "Harvard University", "degree": null, "dates": "1973 - 1975"}
  ]
}

$3.50 per 1,000 profile results. No login required on your end, no browser extension, no manually copy-pasting URLs one at a time.

And the part that actually matters if you're paying for this kind of data: you're only billed for profiles that come back with real data. Private accounts, deleted profiles, blocked lookups — those get logged and skipped, never charged. That sounds obvious until you notice how many scrapers don't do it.

Why that billing promise is harder to keep than it sounds

"No cookies required" shows up in a dozen scraper listings. It's not a trick — LinkedIn serves a genuinely public, server-rendered version of a profile to anyone who isn't logged in, as long as the owner hasn't restricted visibility. The full experience and education history live on their own separate pages, still public, still no login. That's the entire mechanism.

The catch is that the same trust gets pulled instantly if you look automated. A plain request with a normal browser User-Agent got blocked on the first handful of calls — not a 403 or 429, but a non-standard HTTP 999, specific to LinkedIn's bot defense.

A residential proxy didn't fix it. What did: picking up the same visitor cookies a real browser carries before ever loading a profile — one warm-up request to the homepage, a full set of browser-shaped headers, and a Referer chain between requests. Same IP, same machine: blocked every time without it, working every time with it.

The second problem showed up once the main page was reachable: a block on just the experience or education sub-page — after the main page had already succeeded — was killing the entire lookup and discarding data that was already good. Fixed by treating sub-page failures as recoverable: return what you have, leave that one section empty, don't burn a whole session re-fetching data you already got.

Both of those are the difference between "no cookies required" meaning something and it just meaning the empty rows are cheaper to produce.

Try it

Packaged as a bulk LinkedIn profile lookup on Apify, no login needed on your end: Reliable LinkedIn Profiles