LinkedIn Network Scraper (Open To Work & Hiring Badges) avatar

LinkedIn Network Scraper (Open To Work & Hiring Badges)

Pricing

from $4.99 / 1,000 results

Go to Apify Store
LinkedIn Network Scraper (Open To Work & Hiring Badges)

LinkedIn Network Scraper (Open To Work & Hiring Badges)

LinkedIn Network Scraper: Find profiles with Open to Work and Hiring badges, extracting names, job titles, companies, locations, profile URLs, and available professional details. Build targeted datasets for recruitment, hiring research, B2B prospecting, and talent intelligence.

Pricing

from $4.99 / 1,000 results

Rating

0.0

(0)

Developer

API Empire

API Empire

Maintained by Community

Actor stats

0

Bookmarked

3

Total users

0

Monthly active users

3 days ago

Last modified

Share

Export your own LinkedIn connections, same as the base actor — names, headlines, photos, vanity URLs, connection dates — plus the badge LinkedIn draws on each connection's photo when they turn on Open to work or Hiring. Read straight out of the response the base already fetches: zero extra requests. Default mode returns the short list — only connections currently flying one of the two badges — instead of your whole address book.

Why this exists

An in-house recruiter or a founder with an open role wants the handful of people already inside their network whose situation just changed, not a 2,000-row export to sift through by hand. This variant reads LinkedIn's own signal off the photo frame and lets you keep only the rows that carry it.

⚠️ Name honesty — read this before relying on the "Hiring" half

The badge field (frameType) is a passthrough of whatever string LinkedIn's payload carries. Two values have ever been observed:

  • OPEN_TO_WORK — verified repeatedly, on two different accounts, on two different days.
  • HIRING — observed once, on one account, on 2026-08-15, through a session that no longer exists. A fresh live check performed during this build (2026-08-16, a different account) did not see it. It may simply be rarer, or account-dependent — but it has not been re-confirmed since.

The code handles either value correctly either way (it is a string comparison, not a hard-coded pair of booleans), and the hiring filter mode and the HIRING value will work the moment LinkedIn's payload shows it on a run. Just don't expect a guaranteed row for it on every network.

What's new vs. the base actor

FieldTypeWhat it is
badgeFilterselectWhich badge-carrying rows survive the run. Default open_to_work_or_hiring — the short list.
includeBadgeEvidencebooleanAdds badgeCaption (LinkedIn's own wording) and framedPicture (the framed photo URL). Default on.
includeMemberIdbooleanAdds memberId — LinkedIn's permanent internal id, stable across vanity-URL changes. Default on.

New output columns (appended after the base's 9): frameType, hasBadge, badgeCaption, framedPicture, memberId. badgeCaption, framedPicture and memberId are omitted entirely (not emitted as null) when their toggle is off.

What a missing badge means

frameType absent means "no photo frame right now." It does not mean "not open to work." LinkedIn also has a recruiters-only open-to-work setting that never renders as a photo frame and cannot be read from this payload. Never read a badge-less row as a negative signal.

Row count expectations

With the default filter, most runs return a small fraction of your network — that is the intended shape of this variant, not a bug. Badge prevalence varies a lot by network; on the two accounts measured during development it ranged from 1-in-5 to 3-in-38. A run with zero matching rows on a real, populated network is a plausible, honest outcome — set badgeFilter to everyone to audit the whole network with badge columns attached and confirm the cookie/session itself is fine.

Everything the base actor does, unchanged

Same 9 base output fields in the same order and meaning, same 6 base input fields in the same order with the same defaults, same proxy escalation ladder (direct → datacenter → residential), same paging and date-limit behavior, same li_at cookie requirement. This variant adds columns and a row filter; it does not change how the base fetches or paginates your network.

Known base-level limitation (inherited, not introduced by this variant)

A li_at cookie pasted from your browser is bound to that browser's IP and TLS fingerprint. Submitted from a different network (including Apify's own proxy pool), LinkedIn can reject every request with a 302 redirect/throttle signal on every proxy tier, even a cookie that is currently valid in your own browser. This is base behavior, verified again during this build, and it is not something this variant changes or can fix — see the base actor's own li_at field description for how to fetch a cookie, and expect to re-fetch it if a run comes back empty on an account you know has connections.