It's 11pm. A deliverable for a client is due at 9am: 300 LinkedIn job postings for a niche search, filtered by location and posting date, ready to import into a spreadsheet. You kick off the scraper you've been using, go make coffee, come back to a "success" log and a dataset full of... blank rows. Not an error. Not a crash. Just empty fields where real job postings used to be, scattered through the results with no way to tell which rows are real without opening every URL by hand.
That's the actual failure mode of most LinkedIn scrapers: they don't fail loudly, they fail quietly mid-run - and you get charged for the empty rows exactly the same as the real ones.
What you get
Search LinkedIn job postings by keywords, location, workplace type (on-site / remote / hybrid) and posting date - no cookies, no login, no LinkedIn account required. For every real match:
- Title, company, location, posting date, direct URL
- Seniority level, employment type, job function, industries, applicant count
- Full job description
Optionally, layer in results straight from a target company's Greenhouse or Lever board - useful when you already know which companies you're watching.
A row is only ever pushed to the dataset - and only ever billed - if it actually carries real data. If LinkedIn blocks a page on every attempt, the run just returns fewer results. It never fabricates a placeholder row and charges you for it.
The one rule behind it
LinkedIn blocks automated requests with a non-standard status code, not a normal 403 - and it does it regardless of proxy unless the request first behaves like a real browser session. This actor handles that under the hood: warms up a session, rotates to a fresh identity if one gets blocked, and retries the exact page that failed rather than skipping ahead. If a job's detail page still can't be reached after that, the job is kept with the fields it already has instead of being thrown away entirely - partial-but-real beats all-or-nothing, on every actor in this line.
Top comments (0)