DEV Community: Andrew

Find people asking for what you sell, using LinkedIn post search

Andrew — Mon, 17 Aug 2026 01:00:44 +0000

The best lead you will ever get is someone publicly asking for the thing you sell.

Not a scraped list. Not a cold list bought from a broker. An actual person, this week, writing "can anyone recommend a good X" to their network — and waiting for replies.

Those posts exist constantly. The problem is that LinkedIn's search box is built for browsing, not monitoring: you cannot schedule it, diff it against yesterday, or get the results out. So people either check manually until they get bored, or never look at all.

This is a small pipeline that does the looking.

Intent lives in a handful of phrases

Buying intent on LinkedIn is remarkably formulaic. Almost all of it shows up as one of:

"can anyone recommend"
"looking for a tool"
"any alternatives to"
"we're hiring" (intent for recruiters)
"does anyone use"
"switching from"

That last one is the sharpest. Someone saying "switching from X" is a person mid-decision, with the incumbent named for you.

The trick is that these are phrases, not topics. Searching "CRM" gets you a firehose of marketing. Searching "any alternatives to" gets you a short list of people with a live problem.

Pulling the posts

I'm using an Apify Actor that runs LinkedIn's post keyword search and returns structured results. No login, no cookie to paste from your browser, no account to connect.

curl -X POST \
  "https://api.apify.com/v2/acts/data_pool~linkedin-post-scraper/run-sync-get-dataset-items" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "keywords": ["any alternatives to", "can anyone recommend"],
    "maxItems": 100,
    "datePosted": "24h",
    "sortBy": "date_posted"
  }'

Each keyword runs as its own search and results are de-duplicated across them, so overlapping phrases do not produce duplicate rows.

What comes back

{
  "postUrl": "https://www.linkedin.com/posts/ias07_generativeai-...",
  "postUrn": "urn:li:activity:7...",
  "text": "Generative AI is moving beyond simple conversations...",
  "postedAtIso": "2026-08-16T10:39:56.510Z",
  "author": {
    "name": "Jane Doe",
    "headline": "VP Sales @ Acme",
    "profileUrl": "https://www.linkedin.com/in/jane-doe",
    "type": "person"
  },
  "stats": { "reactions": 12, "comments": 0, "reposts": 0, "impressions": 0 },
  "isRepost": false,
  "matchedKeyword": "any alternatives to"
}

Two fields do most of the work downstream:

author.headline is your qualifier. It is the single cheapest way to tell a VP of Engineering from a student, without another API call.
author.type is person or company. Company pages post too, and they are almost never the lead you want.

Also worth knowing: stats.impressions is often 0. LinkedIn only exposes impressions on some posts, so treat it as a bonus rather than a field you can sort by.

Filtering down to the ones worth reading

Raw keyword matches still contain a lot of noise — recruiters quoting the phrase, people describing what they built, reposts of someone else's question. A few cheap rules cut most of it.

import os
import re
import requests

ACTOR = "data_pool~linkedin-post-scraper"
URL = f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items"

INTENT = [
    "any alternatives to",
    "can anyone recommend",
    "looking for a tool",
    "does anyone use",
    "switching from",
]

# Headlines that are almost never the buyer for a B2B tool.
EXCLUDE_HEADLINE = re.compile(
    r"\b(student|intern|seeking|open to work|recruiter|talent acquisition)\b",
    re.I,
)


def search(keywords, hours="24h", limit=100):
    resp = requests.post(
        URL,
        headers={"Authorization": f"Bearer {os.environ['APIFY_TOKEN']}"},
        json={
            "keywords": keywords,
            "maxItems": limit,
            "datePosted": hours,
            "sortBy": "date_posted",
        },
        timeout=300,
    )
    resp.raise_for_status()
    return resp.json()


def worth_reading(post):
    author = post.get("author") or {}
    if author.get("type") != "person":
        return False                       # company pages aren't leads
    if post.get("isRepost"):
        return False                       # they're amplifying, not asking
    if EXCLUDE_HEADLINE.search(author.get("headline") or ""):
        return False
    return True


for post in search(INTENT):
    if not worth_reading(post):
        continue
    author = post["author"]
    text = " ".join((post.get("text") or "").split())
    print(f"{author['name']} — {author.get('headline', '')}")
    print(f"  \"{text[:160]}\"")
    print(f"  {post['postUrl']}")
    print(f"  matched: {post['matchedKeyword']}  ·  {post['stats']['comments']} comments\n")

The isRepost check matters more than it looks. A repost means that person is amplifying someone else's question, not asking one — and reposts are a large share of what any keyword search returns.

The second, better use: read the replies

Here is the part most people miss.

When someone posts "can anyone recommend a tool for X", the interesting audience is not only the author. It is everyone who replied. Those people either have an opinion about the category or the same problem. A post with 40 comments asking for recommendations is 40 qualified people, plus one.

So the pipeline extends naturally: take the postUrl values with a healthy stats.comments count, and pull everyone who engaged with them using a post engagement Actor. You go from "someone asked about my category" to "here are the fifty people in that conversation, with profile links."

high_signal = [
    p["postUrl"] for p in search(INTENT)
    if worth_reading(p) and p["stats"]["comments"] >= 5
]
# feed high_signal into the engagement Actor to get the participants

That is a fundamentally different list from a scraped export. Every person on it opted into a conversation about the problem you solve, in public, this week.

Running it daily

Keep it to the last 24 hours and schedule it. A monitoring query wants recency, not the all-time best posts:

datePosted: "24h" and sortBy: "date_posted" so each run only sees new material
cron or GitHub Actions on a schedule, token in a secret
Push the digest somewhere you already look — Slack DM beats a log file you forget to open
Deduplicate on postUrn, which is stable across runs

Other things the same query shape is good for

Competitor monitoring — search their brand name, and you get both praise and complaints. The complaints are leads.
Content research — drop the date filter, sort by relevance, and rank by stats.reactions to see what actually resonates in a niche before writing your own post.
Recruiting signals — "we're hiring" plus a role keyword surfaces teams growing right now, often before the job posting appears.
Community discovery — the same names recurring across a topic's posts are that topic's actual practitioners.

What it costs

$1.50 per 1,000 posts returned, no subscription and no per-run fee.

A daily monitoring run pulling 100 posts is 3,000 posts a month — about $4.50, most or all of which Apify's free monthly credit absorbs. Intent monitoring is cheap because the useful queries are narrow by construction.

The honest caveats

LinkedIn caps what any search returns — realistically a few hundred results per query, not everything ever posted. Several narrow phrase searches beat one broad topic search, which is also better for signal.
Results are not deterministic. Ranking shifts between runs, so a daily digest is "what surfaced today", not a complete index. Use recency sorting if you need runs to be comparable.
Phrase matching is fuzzy. You will get posts that contain your phrase in a different sense. The filters above help; nothing removes it entirely.
stats.impressions is frequently 0 — available for some posts only.
These are real people. Names, headlines and profile URLs are personal data under GDPR and similar laws, and public visibility is not the same as unrestricted use. Have a lawful basis, and if you reach out, reference the actual post — replying to a real question is legitimate; blasting a scraped list is what gives this whole category a bad name.

Wrapping up

The shift that made this useful was searching for phrases that indicate a decision rather than topics. "CRM" is a firehose. "any alternatives to" is a queue of people with a live problem and a deadline.

And once you have those posts, the comments are where the actual audience is.

Automate your job search: a daily LinkedIn jobs pipeline in Python

Andrew — Tue, 11 Aug 2026 20:09:47 +0000

Job hunting has a timing problem that nobody warns you about.

A posting goes up. For the first few hours it has a handful of applicants. By day three it has two hundred, a recruiter has stopped reading carefully, and your carefully tailored application is row 187 in an ATS.

You cannot control how good the other 186 candidates are. You can control whether you were row 8 instead. That is an automation problem, and it takes about forty lines of Python.

The two filters that actually matter

LinkedIn's job search has a lot of knobs. For this purpose, two of them do most of the work:

Posted in the last 24 hours. Anything older is already contested.
Under 10 applicants. LinkedIn exposes this, and it is the single best proxy for "you will actually be read."

Everything else — seniority, remote, job type — narrows the funnel to roles you would actually take. But the two above are what turn a job feed into an edge.

Checking that by hand every morning is exactly the kind of thing you stop doing on day four. So let's not do it by hand.

One call for the data

I am using an Apify Actor that queries LinkedIn's job search and returns structured results. The endpoint below starts a run, waits, and hands back the rows — no polling loop, no login, no cookie to extract from your browser.

curl -X POST \
  "https://api.apify.com/v2/acts/data_pool~linkedin-jobs-scraper/run-sync-get-dataset-items" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "keywords": ["backend engineer", "platform engineer"],
    "maxItems": 100,
    "location": "Berlin, Germany",
    "workplaceType": ["remote", "hybrid"],
    "datePosted": "24h",
    "sortBy": "date",
    "under10Applicants": true
  }'

Each keyword runs as its own search, and results are de-duplicated across them, so overlapping search terms do not produce duplicate rows.

What comes back

{
  "jobId": "4012345678",
  "jobUrl": "https://www.linkedin.com/jobs/view/4012345678/",
  "title": "Senior Backend Engineer",
  "location": "Berlin, Germany",
  "workplaceType": "hybrid",
  "listedAtIso": "2026-08-11T09:12:00Z",
  "easyApply": true,
  "fewApplicants": true,
  "isPromoted": false,
  "company": {
    "name": "Acme GmbH",
    "profileUrl": "https://www.linkedin.com/company/acme-gmbh"
  },
  "insights": ["Actively hiring"],
  "matchedKeyword": "backend engineer"
}

Three fields deserve attention:

jobId is stable across runs. That is your deduplication key — without it, a daily job will keep showing you Monday's postings all week.
workplaceType comes back as a raw enum (on_site, remote, hybrid), not a pretty label. Map it before it reaches a human.
isPromoted tells you the company paid to boost the listing. Not automatically bad, but a promoted post that is three weeks old is a different signal from a fresh organic one.

The daily script

This is the whole thing: fetch, drop anything seen before, print a digest.

import json
import os
import pathlib
import requests

ACTOR = "data_pool~linkedin-jobs-scraper"
URL = f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items"
SEEN = pathlib.Path("seen_jobs.json")

WORKPLACE = {"on_site": "On-site", "remote": "Remote", "hybrid": "Hybrid"}

SEARCH = {
    "keywords": ["backend engineer", "platform engineer"],
    "maxItems": 100,
    "location": "Berlin, Germany",
    "workplaceType": ["remote", "hybrid"],
    "datePosted": "24h",
    "sortBy": "date",
    "under10Applicants": True,
}


def fetch_jobs():
    resp = requests.post(
        URL,
        headers={"Authorization": f"Bearer {os.environ['APIFY_TOKEN']}"},
        json=SEARCH,
        timeout=300,
    )
    resp.raise_for_status()
    return resp.json()


def main():
    seen = set(json.loads(SEEN.read_text())) if SEEN.exists() else set()

    fresh = []
    for job in fetch_jobs():
        job_id = job.get("jobId")
        if not job_id or job_id in seen:
            continue
        seen.add(job_id)
        fresh.append(job)

    for job in fresh:
        company = (job.get("company") or {}).get("name", "unknown")
        flags = []
        if job.get("easyApply"):
            flags.append("Easy Apply")
        if job.get("fewApplicants"):
            flags.append("<10 applicants")
        suffix = f"  [{', '.join(flags)}]" if flags else ""
        print(f"{job['title']} — {company}")
        print(f"  {job.get('location', '')} · {WORKPLACE.get(job.get('workplaceType'), '')}{suffix}")
        print(f"  {job.get('jobUrl', '')}\n")

    SEEN.write_text(json.dumps(sorted(seen)))
    print(f"{len(fresh)} new posting(s).")


if __name__ == "__main__":
    main()

Run it, and you get only what appeared since yesterday.

One gotcha: this endpoint returns HTTP 408 if the run takes more than 5 minutes. For a daily search that is not a concern, but if you ever crank maxItems into the thousands, switch to the async pattern (POST /runs, then poll).

Actually running it every day

The script is deliberately boring so you can schedule it however you like:

cron, if you have a machine that is always on: 0 8 * * * cd ~/jobsearch && APIFY_TOKEN=... python daily.py >> log.txt
GitHub Actions on a schedule: trigger, with the token as a repository secret — free, and no machine to maintain.
n8n / Make / Zapier, if you would rather the output land in Google Sheets or a Slack DM than a terminal. The same call works as a single HTTP Request node.

The digest is more useful pushed somewhere you already look. Slack DM, a Telegram bot, or an email to yourself all beat a log file you forget to open.

Filters worth knowing about

Field	Why you'd use it
`under10Applicants`	The highest-signal filter here. Apply while the pile is small.
`datePosted: "24h"`	Keeps a daily run cheap and the results genuinely new.
`easyApply`	One-click applications, if you're playing a volume strategy.
`workplaceType`	`remote` is often geo-restricted anyway — pair it with `location`.
`seniority`	`entry_level` through `executive`; filters out the mismatches.
`company`	Watch one employer's hiring. Useful when you're targeting a shortlist.

What it costs

$0.50 per 1,000 job postings returned, with no per-run fee and no subscription.

A realistic daily search pulling 100 postings costs about $1.50 a month — comfortably inside Apify's free monthly credit, so a personal job search runs at no cost. The pricing only starts to matter if you are feeding a job board rather than a job hunt.

The honest caveats

LinkedIn caps what any search returns. Realistically a few hundred results per query, not every posting in existence. Several narrow searches beat one enormous one.
Results are not deterministic. LinkedIn's ranking shifts between runs, so treat a daily digest as "what surfaced today", not a complete index.
under10Applicants reflects LinkedIn's own counter, which updates on its own schedule. Treat it as a strong hint, not a guarantee.
The applicant count is not the whole story. Being early gets you read. It does not get you hired — that part is still on you and your CV.

Wrapping up

The interesting part of this was not the scraping. It was noticing that "posted in the last 24 hours" plus "under 10 applicants" is a genuinely different product from "job search", and that the only thing standing between those two things was a scheduled script and a stable ID to deduplicate on.

If you are hunting right now: automate the finding, and spend the time you save on the applications themselves.

Disclosure: I built the Actor used in this post. Costs quoted are its public list price in August 2026, and the caveats above are the same ones I would give you in person.

Export everyone who engaged with a LinkedIn post — no login, no cookies

Andrew — Tue, 11 Aug 2026 17:19:22 +0000

If you post on LinkedIn, the people who react and comment are the warmest leads you will ever get. They saw your thing, they cared enough to click, and they raised their hand in public.

Getting that list out of LinkedIn is annoying in three specific ways. This post is about making it one API call.

Why the usual approaches hurt

1. Most tools want your session cookie. You open DevTools, copy your li_at value, and paste it into someone else's server. Now your personal account is the one making automated requests, and if the tool gets rate-limited or flagged, it is your account that eats the restriction. That is a bad trade for a lead list.

2. Reactions and comments are usually two separate products. The two biggest tools in this niche sell "post comments" and "post reactions" as different scrapers. Someone who liked and commented shows up in both exports, so you run two jobs, download two files, and write dedup logic before you have anything usable.

3. The output is nested. You want a spreadsheet. You get JSON with a person object inside every row.

One call instead

I will use an Apify Actor that does reactions and comments in a single run and merges duplicate people. The endpoint below starts the run, waits, and returns the rows directly — no polling loop.

curl -X POST \
  "https://api.apify.com/v2/acts/data_pool~linkedin-post-engagement-scraper/run-sync-get-dataset-items" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "postUrls": ["https://www.linkedin.com/feed/update/urn:li:activity:7491138591868469248/"],
    "engagementTypes": ["reactions", "comments"],
    "maxItemsPerPost": 100,
    "dedupePeople": true
  }'

postUrls accepts normal post links, lnkd.in short links, or raw urn:li:activity:... IDs, so you can throw whatever format you already have at it.

What comes back

One object per person:

{
  "postUrl": "https://www.linkedin.com/feed/update/urn:li:activity:7491138591868469248/",
  "postAuthorName": "Jane Doe",
  "engagementTypes": ["reaction", "comment"],
  "reactionValue": "PRAISE",
  "commentText": "This matches what we're seeing too.",
  "commentedAt": "2026-07-01T12:00:00Z",
  "person": {
    "name": "John Smith",
    "headline": "VP Engineering @ Acme",
    "profileUrl": "https://www.linkedin.com/in/john-smith",
    "type": "individual"
  }
}

Two things worth knowing about this shape, because they will bite you otherwise:

engagementTypes is an array. Someone who both reacted and commented has ["reaction", "comment"] in a single row rather than two rows. That is the dedup doing its job.
person.type is "individual" or "organization" — company pages react to posts too. If you are building an outreach list you almost certainly want to filter the organizations out.

Flattening it into a lead list

import os
import requests

ACTOR = "data_pool~linkedin-post-engagement-scraper"
URL = f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items"

def engagers(post_url, limit=100):
    resp = requests.post(
        URL,
        headers={"Authorization": f"Bearer {os.environ['APIFY_TOKEN']}"},
        json={
            "postUrls": [post_url],
            "engagementTypes": ["reactions", "comments"],
            "maxItemsPerPost": limit,
            "dedupePeople": True,
        },
        timeout=300,
    )
    resp.raise_for_status()

    for row in resp.json():
        person = row.get("person") or {}
        if person.get("type") != "individual":
            continue  # skip company pages
        yield {
            "name": person.get("name", ""),
            "headline": person.get("headline", ""),
            "profile_url": person.get("profileUrl", ""),
            "engagement": " + ".join(row.get("engagementTypes") or []),
            "comment": row.get("commentText", ""),
        }

for lead in engagers("https://www.linkedin.com/feed/update/urn:li:activity:7491138591868469248/"):
    print(lead)

That is a CSV away from being usable.

One gotcha: this endpoint returns HTTP 408 if the run takes longer than 5 minutes. Keep maxItemsPerPost in the low hundreds, or switch to the async pattern (POST /runs, then poll) for genuinely large jobs.

Doing it without code

If you would rather wire it into a workflow, the same call works as a single HTTP Request node in n8n, which is handy when the destination is Google Sheets or Slack rather than your own script. The only setup is a Header Auth credential holding Bearer <token>.

What it costs

Per 1,000 people returned, at list prices as of August 2026:

Tool	Reactions	Comments	Both from one post
This Actor	$1.50 / 1k	$1.50 / 1k	one run
Alternative A (~6,000 users)	$2.00 / 1k	$2.00 / 1k	two separate Actors
Alternative B (~4,800 users)	—	$5.00 / 1k	two separate Actors

The "both from one post" column is the part that actually matters. If you want reactors and commenters, the alternatives mean two runs and your own dedup pass, so the real gap is wider than the per-1000 numbers suggest.

Apify's free tier includes monthly credit, so a few thousand engagers costs nothing to try.

The honest caveats

Coverage is whatever LinkedIn surfaces for that post at that moment. Posts with tens of thousands of reactions come back partially. Nobody in this category gets 100%, whatever the marketing says.
Reactions have no timestamp. LinkedIn timestamps comments but not reactions, so commentedAt is empty for reaction-only rows. Do not build "engaged in the last 24h" logic on it.
This is personal data. Names, headlines, and profile URLs of identifiable people are personal data under GDPR and similar laws. Publicly visible is not the same as unrestricted — you still need a lawful basis to process it, and cold outreach in the EU has real requirements. Scraping it is the easy part; using it responsibly is the part worth thinking about.

Wrapping up

The pattern that made this simple was picking a tool that treats "everyone who engaged" as one dataset rather than two products, and using a sync endpoint so there is no polling loop. Both decisions removed more code than any clever scraping trick would have.

Disclosure: I built the Actor used in this post. The comparison figures are the list prices published on the Apify Store in August 2026; I have left the alternatives unnamed because the point is the structure of the pricing, not a swipe at anyone — the two tools referenced are easy to find and worth comparing for yourself. The caveats section is the same thing I would tell you if you asked me whether to buy it.