LinkedIn Network Scraper (Open To Work & Hiring Badges)
Pricing
from $4.99 / 1,000 results
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
Maintained by CommunityActor stats
0
Bookmarked
3
Total users
0
Monthly active users
3 days ago
Last modified
Categories
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
| Field | Type | What it is |
|---|---|---|
badgeFilter | select | Which badge-carrying rows survive the run. Default open_to_work_or_hiring — the short list. |
includeBadgeEvidence | boolean | Adds badgeCaption (LinkedIn's own wording) and framedPicture (the framed photo URL). Default on. |
includeMemberId | boolean | Adds 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.