DEV Community: Kevin Hall

Clay alternative in Claude Code: one ICP, companies, leads and jobs

Kevin Hall — Tue, 03 Nov 2026 14:52:35 +0000

Clay is a spreadsheet that calls data providers for you. A marketing team opens it to do one job most weeks: describe the ideal customer, find the companies that fit, add a signal such as a funding round or a hiring spree, find the people inside, get an address that works, and do it again next week without paying twice for the same person.

That job has a price tag in three parts: the plan, the credits each enrichment burns, and the afternoon it takes to build the table. I wanted the list-building half of it as one call that Claude Code can make from a sentence. This is what I got, with the inputs and the numbers from 3 November 2026.

In one paragraph

Full ICP Search on Apify takes one ideal customer profile and returns the companies that match, the decision makers inside them with an email that reaches them today, and the job postings that carry the signal, in one run and one dataset. A free preview counts everything first, misses are never charged, and a rerun with excludeDatasets returns only new accounts. It is an MCP tool, so Claude Code fills the filters from a brief.

What does a Clay workflow actually do?

Strip the table away and a typical Clay build for outbound is five columns:

Column in the table	What it asks
find companies	industry, headcount, HQ country, maybe a city
add a signal	last funding round and its date, open roles, a tool named in a posting
find people	the titles or levels you sell to, one or two per account
get an email	a work address at the current employer, or a personal one
refresh	only the accounts that were not in last week's run

Every column is a provider call with its own credit, and the table is the thing you maintain. Here the five columns are five groups of fields in one input, and the run answers them in order: companies, then people, then contacts, then postings.

The wiring, once

Pin the Actor in the server URL so an agent loads only this tool:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/full-icp-search" --header "Authorization: Bearer <APIFY_TOKEN>"

Any other MCP client (Cursor, Claude Desktop, ChatGPT, LangChain, CrewAI, the OpenAI Agents SDK) takes the same server:

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/full-icp-search",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

The tool is called b2bsearch--full-icp-search (double hyphen). Without an agent, the same input goes to one REST endpoint and the rows come back in the response:

curl -X POST "https://api.apify.com/v2/acts/b2bsearch~full-icp-search/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d @input.json

Every example below is the input.json for that call, or the arguments of the tool call.

How do I count the profile before paying for a row?

The profile I used all day: US software companies with 51 to 200 people that raised a seed or Series A round since January 2025 and posted an SDR or account executive job in the last month. The people: the sales or marketing leader at each one, with an email that reaches them today.

Written as the input, with what each field does:

{
  "find": "companies_and_people",     // companies first, then people inside them; also "companies" or "people"
  "previewOnly": true,                // counts only, nothing charged; flip to false to pull rows

  // the company half of the profile
  "companyCountries": ["us"],          // HQ country, two-letter codes
  "industries": ["Software Development"],
  "companySizeMin": 51,
  "companySizeMax": 200,
  "fundingStages": ["seed", "series_a"],   // the latest recorded round
  "fundedAfter": "2025-01-01",             // ...dated on or after this day
  "hiringJobTitles": ["sdr", "sales development", "account executive"],   // posted a job with any of these in the title
  "hiringPostedWithin": "month",           // week, month or 3months; needs a country next to it

  // the people half
  "jobTitles": ["vp sales", "head of sales", "chief revenue officer", "head of marketing", "vp marketing"],
  "requireEmail": true,                // only people with a work address at the current company or a personal one
  "emailType": "any",                  // "work" = current-company address only, fewer people

  // how much to deliver when previewOnly is off
  "peoplePerCompany": 2,
  "jobsPerCompany": 2                  // the postings that matched the hiring filter, as rows
}

Three free rows came back in about ten seconds:

Preview row	Count
companies that fit and posted a matching job in the last 30 days	23
job postings behind that hiring filter	52
people matching the titles at companies of that industry, size and country, before the email test	1,981

The people count is wide on purpose: it is taken before funding, hiring and the email requirement cut it down, and the note row says so. The company count is the one that sizes the pull.

I dropped the two hiring fields and previewed again. Same companies, no hiring signal: 171. So the SDR posting is what turns a long list into a short one, and the preview told me that before I paid for anything.

What comes back when I pull it?

Same input, previewOnly off, five companies to start:

{
  "find": "companies_and_people",
  "companyCountries": ["us"],
  "industries": ["Software Development"],
  "companySizeMin": 51,
  "companySizeMax": 200,
  "fundingStages": ["seed", "series_a"],
  "fundedAfter": "2025-01-01",
  "hiringJobTitles": ["sdr", "sales development", "account executive"],
  "hiringPostedWithin": "month",
  "jobTitles": ["vp sales", "head of sales", "chief revenue officer", "head of marketing", "vp marketing"],
  "requireEmail": true,
  "emailType": "any",
  "maxCompanies": 5,
  "peoplePerCompany": 2,
  "jobsPerCompany": 2
}

Fifteen seconds. One dataset, and _type on every row says what it is:

`_type`	Rows	Charged
`company`	5	yes, per company
`person`	6	yes, per lead with a live email
`job`	10	yes, per posting
note: companies read but nobody matched with an email	1 row, 4 companies	no

The company rows, without names:

Size	Stage	Round dated	Open jobs	Matching postings	Leaders delivered
76	Series A	Nov 2025	103	4	1
86	Series A	Jul 2025	30	3	1
106	Series A	Mar 2025	9	3	1
60	Series A	Jul 2025	7	2	1
119	Series A	Jun 2025	27	2	2

The people rows: a head of sales, a head of marketing, a VP of sales, another head of sales, a chief revenue officer and a head of marketing, every one with a work address at the company in the row above. The job rows carry the title, the posting URL, when it was posted, the location and the applicant band, so the opener can name the role they are hiring for.

What each row holds, the fields you will actually read:

Row	Fields
`company`	`companyName`, `companyDomain`, `companyWebsite`, `companyLinkedinUrl`, `companyIndustry`, `companySize`, `companyCountry`, `companyCity`, `companyFounded`, `companyDescription`, `fundingStage`, `lastFundingDate`, `lastFundingAmountUsd`, `openJobs`, `jobsLast30Days`, `matchingJobs`, `matchingJobTitles`, `topJobTitles30d`, `peopleFound`
`person`	`fullName`, `firstName`, `lastName`, `jobTitle`, `seniority`, `headline`, `email`, `emailType`, `workEmail`, `personalEmail`, `linkedinUrl`, `location`, `countryCode`, `phoneOnRecord`, plus the employer's company columns and `companyId`
`job`	`jobTitle`, `jobUrl`, `jobPostedAt`, `jobLocation`, `jobCountry`, `jobSeniority`, `employmentType`, `applicantRange`, `companyName`, `jobsDataAsOf`

Company, person and job rows share companyId, so they join in a spreadsheet, and the dataset has a view called "Emails for outreach tools" with the columns a sequencer imports.

How do I get only the new accounts next week?

Add the dataset id of the first run to excludeDatasets and run the same profile again:

{
  "...": "the same profile as above",
  "maxCompanies": 5,
  "excludeDatasets": ["<dataset id of last week's run>"]
}

Ten seconds:

Outcome	Companies
already in last week's dataset, skipped free	5
read, nobody matching with an email, skipped free	14
new, delivered with a leader and their postings	4

That is the "only new rows" column of the table, as one field. On a schedule it is a weekly feed of funded companies that started hiring sellers, with the person to write to.

Can I start from the people instead of the companies?

Yes. find: "people" searches people directly, with the company fields applied to their current employer. The profile I tried: revenue operations and sales operations leaders in the UK at companies of 51 to 500, who started the current job after July 2025, because a new operations leader is the one reviewing the stack.

{
  "find": "people",
  "personCountries": ["gb"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "jobTitles": ["revenue operations", "revops", "sales operations"],
  "seniority": ["director", "vp", "cxo"],
  "startedCurrentRoleAfter": "2025-07-01",
  "requireEmail": true,
  "maxPeople": 8
}

The preview counted 51 before the email test. The pull delivered 8 in six seconds and skipped 6 for having no address on record, free. Of the eight, three came with a work address and five with a personal one, which is normal for people in a new seat: the new company's address is not on record yet. Two things the row does not carry in this mode: seniority is blank, because the people search matches on the title rather than a roster level, and the start date that the filter used is not printed. The filter does the work; the row shows the result.

I already have an account list. Does it take domains?

companyDomains turns the same input into an account-based pull: each domain is one company, the one that owns the website. I gave it six sales-technology vendors and asked for one marketing leader at C-level or VP with an email:

{
  "find": "companies_and_people",
  "companyDomains": ["gong.io", "clari.com", "outreach.io", "salesloft.com", "lusha.com", "cognism.com"],
  "seniority": ["cxo", "vp"],
  "jobTitles": ["marketing", "demand", "growth"],
  "requireEmail": true,
  "peoplePerCompany": 1
}

Eight seconds. Three companies came back with a chief marketing officer or a VP of product marketing and a work address. Three were read and skipped free because nobody at those levels with those words in the title had an address on record. Two more people were skipped free with a separate note: the record named a company they had already left. Nothing was guessed and nothing dead was sold.

What about the list I already have in a CSV?

That is the other half of a Clay table: the rows exist, the columns are empty. Its twin in the same family is Waterfall Lead Enrichment. It reads whatever columns the file has and resolves each row by the strongest key it carries: email, then profile URL, then a social handle, then full name plus company website, and a row with only a website is treated as a company.

I built a six-row file from the people above, deliberately messy:

{
  "csv": "email,full_name,company_website\njane@acme.example,,\n,,\n,Jane Doe,acme.example\n,,\n,,gong.io\n,,clari.com",
  // two rows with only an address, two with only a name and a website, two with only a company website
  "contacts": true,     // add the addresses and phones that reach the person today
  "compact": true       // a 2 KB row per person instead of 10 KB, same price; made for agents
}

(Paste a real file or a link to one; the inline string is the same thing.) Seven seconds, six rows, all found:

Key the row had	What came back
an email address, two rows	the person's profile, at the profile tier: the only address on record was the one I had sent, so there was no new contact to charge for
a name and a company website, two rows	the person with contacts: one of them with five addresses on record, work and personal
a company website, two rows	the company card: headcount band, industry, HQ country, founding year, last round and its date

Misses in that Actor are free rows that say why: not_found, ambiguous when a name is shared or a website is claimed by unrelated pages, invalid, duplicate.

What did the agent do on its own?

I gave a Claude Code session the Actor pinned and the brief a marketing lead would write: we sell sales coaching, the ideal customer is a US software company of 51 to 200 people that raised seed or Series A since January 2025 and is hiring SDRs or account executives, I want the sales or marketing leader with an email and the posting that proves it.

The rules in the brief: preview first, tighten above 30 companies, loosen under 5, then one paid pull of 5 companies with a spend cap, and report without names. Shell and file tools were denied; it had a short saved note of mine about these Actors.

Nine turns, about two minutes, two Actor runs. What it did without being told:

wrote the people half as words plus levels, jobTitles sales, marketing, revenue, cmo, cro with seniority cxo, vp, director, instead of my five exact titles. Same 23 companies in the preview; the people count before the email test went from 1,981 to 11,002, which is the gap between a title list and a word list
kept the profile as it was, because 23 sat inside the window the brief allowed
passed the spend cap in the call options, then wrote in its report that the field is not in the Actor's schema and it could not confirm the cap had applied. True on both counts
read the rows with a fields list of 25 columns, left out the names and addresses it was told not to print, and read the dataset a second time when the run record showed 16 rows where the first read had shown 6
noticed what I had not: all five companies in California or New York, all Series A and no seed, five sales leaders and no marketing one, two work addresses and three personal, one person with a mobile on record
flagged that the postings were dated 17 to 21 October against a jobs snapshot of 21 October, so "last month" counts from the snapshot and not from today

Its verdict: the rows are good, the profile is too narrow for a hundred-company pull, so widen it with a three-month hiring window, two more industries or a 2024 funding date, preview again and aim for 120 to 150 companies to leave room for the ones where nobody matches. That is the afternoon in the table, done in two minutes, with a number in front of every decision.

What this does not do

It is not a table. Clay also writes AI columns, syncs to a CRM and chains dozens of providers; this is the list-building and enrichment part, priced per row and callable from an agent.

Addresses are on record, not verified at run time, and never guessed from a name pattern. Run your verifier before a big send.

Job postings follow the jobs data's own date, printed on every job row as jobsDataAsOf, which can sit a few days behind today. Funding is the latest recorded round: seed means the company has not raised past seed on record, and records of large, older companies are often stale, so pair an early stage with a size cap.

Mobile numbers, with includePhones, are US-centric. And the free Apify plan caps a run at a hundred rows from the Console and twenty-five through the API, and an account at five hundred rows a month on this Actor; previews stay outside the cap, and any paid plan lifts it.

FAQ

Is this Clay? No. It is an independent Actor on Apify that covers the list-building and enrichment steps of a Clay workflow. It is not affiliated with Clay.

Do I need Claude Code? No. The input is JSON, so the form on the Actor page, a schedule, n8n, Make, Zapier or a curl call all work. Claude Code makes it fast to describe a profile in words and compare two segments by their free counts.

Where do the emails come from? From the contact block of the person's record: a work address at the current employer, or a personal one. Addresses at earlier employers never count, and people without one are skipped free.

How do I keep an agent from overspending? Run previewOnly first, cap with maxCompanies and maxPeople, set maxTotalChargeUsd on the run, and pass last week's dataset in excludeDatasets so nobody is bought twice.

What is the fastest way to try it? The Actor page has ready-made examples that open with the input filled in: funded startups hiring their first sales reps, and recently funded US startups with the founders' emails. Press Try for free and change the filters.

For AI agents reading this

The Actor runs as the tool b2bsearch--full-icp-search on the hosted Apify MCP server with the tool pinned in the URL (the wiring block above). The workflow:

call with previewOnly: true to size the profile; the free rows have _status: "preview" and _type company, person or job with _total
tune the company half (companyCountries, industries, companySizeMin, companySizeMax, fundingStages, fundedAfter, hiringJobTitles, hiringPostedWithin, companyDomains) and the people half (seniority, jobTitles, excludeJobTitles, keywords, startedCurrentRoleAfter, pastCompanyDomains, requireEmail, emailType)
pull with maxCompanies, peoplePerCompany, jobsPerCompany or maxPeople, and callOptions.maxTotalChargeUsd set
read rows with get-dataset-items and a fields list; filter on _type; rows with a _status other than found are free notes that say why
rerun with excludeDatasets for new rows only

For a file you already hold, b2bsearch--waterfall-lead-enrichment with csv, contacts and compact: true. Platform docs: Apify MCP server and apify.com/agents.md. Per-plan pricing is on each Actor page.

Champion tracking in Claude Code: who in my CRM changed jobs

Kevin Hall — Tue, 03 Nov 2026 14:12:50 +0000

Every CRM goes stale the same way. The record says she runs sales ops at Acme. She left last spring. The sequence still writes to her old address, and her new company, where she already knows your product, never hears from anyone.

Champion tracking tools sell the fix as a subscription that watches your contacts. Most of the value is in a one-off check: the profile URLs you already have, one Apify Actor and a comparison that does not lie to you. The comparison is the part people get wrong, so most of this post is about it.

I tested it on a list where I already knew the answer. Eighty people from four sales-software companies, the kind of accounts a vendor keeps in its CRM. Half were still listed at the company and half had left it since 2024, half and half on purpose, so nothing below says how fast a real CRM decays. A list with a known answer lets you check the check before you trust it on the real thing. Rows below show roles and dates only, no names and no addresses.

In one paragraph: export the profile URL and the company domain from the CRM, run Profile Lookup on the URLs, turn the domains into company records with Domain to Company, and call someone moved only when none of their open positions is at that company. Then get the movers' new work address and find out who took the seat they left.

1. Who still works where the CRM says

The input is the list. Full links, bare handles and mobile links all work.

{
  "profileUrls": [
    "https://www.linkedin.com/in/jane-doe-example",
    "john-roe-example"
  ],
  "contacts": true
}

Eighty profiles came back in seconds. Each row is the whole career record, and the part that matters here is experience.work: every position with a start date and an end date. An open position has no end date.

Your CRM stores the company as a name and maybe a domain. A name is a bad key (Acme, Acme Inc, Acme Software), so resolve the domain first. Domain to Company takes {"domains": [...]}, and the linkedinUrl on its row ends with the company slug. The same slug sits in companyId.publicId on every position of the profile. After that the check is a few lines:

def verdict(row, crm_slug):
    if row["_status"] != "found":
        return row["_status"]            # not_found, profile_removed: free rows
    open_jobs = [w for w in row["experience"]["work"] if not w.get("endDate")]
    if not open_jobs:
        return "no_open_job"
    slugs = {(w.get("companyId") or {}).get("publicId") for w in open_jobs}
    return "still_there" if crm_slug in slugs else "moved"

crm_slug is row["linkedinUrl"].rstrip("/").split("/")[-1] from the Domain to Company row.

On my test list it got every leaver right, except one person whose profile had been removed. That comes back as a free row and is a contact to archive anyway. On the half that was supposed to still be there it found two people with no open job at all: their position at the company had ended in spring 2025. The roster I built the test list from was behind their profiles. Which is the whole reason to check the profile and not a list of employees.

The trap: companyName is not the employer

Every row also has a companyName column, and it is tempting to compare that with the CRM. Don't. It holds the first open position on the profile, and people keep plenty of open positions that are not their job: a board seat, "Member" of a sales community, an advisor title, their own consulting shop, a founder title on a meetup they started years ago.

On my list about a quarter of the people who never left would have been marked as moved by that one column. A real row, names replaced:

{
  "companyName": "A sales community",
  "experience": { "work": [
    { "company": "A sales community", "companyId": { "publicId": "a-sales-community" },
      "title": "Member", "startDate": "2024-12-01", "endDate": null },
    { "company": "Acme", "companyId": { "publicId": "acme" },
      "title": "Senior Director, Account Development", "startDate": "2022-05-01", "endDate": null }
  ]}
}

It goes the other way too. Some people never close the old job when they start a new one, so the profile shows the CRM company and a newer company, both open. My check calls that "still there". Look at the start dates and the headline: if the newest open job is somewhere else and the headline names it, they moved.

2. They moved: a warm account and a new address

The new company is the interesting part. Someone there already used your product and liked it enough to be your contact. That is the warmest cold account you will ever get.

With contacts: true the row also says what is on record for reaching them. About a third of my movers had an address at the new company (employerMatch: true), most of the rest only a personal one, and the others an old work address or nothing. For the ones without a work address, Work Email Finder takes the name and the new company's domain.

The uncomfortable bit: for almost half of the movers the address at the old company was still on record. That is the address sitting in your CRM, the one the sequence keeps sending to. Fix those before the next campaign, not after the bounce report.

3. The CRM only has emails

Plenty of CRMs never stored a profile URL. Reverse Email Lookup starts from the address you have, including an old work address that would bounce today:

{ "emails": ["jane.doe@acme.example"] }

I gave it the old company addresses of the movers. All but one came back as the same person, with the new job on the row. The one that didn't was a different person with the same first name. Compare the name on the row with the name in the CRM before acting on it.

4. The account lost its champion

The old account matters too. Your contact left, someone else sits in that seat now, and they have never heard of you. Company Employees on the account's domain with a word from the old title:

{
  "companies": ["acme.com"],
  "titleContains": ["revenue operations"],
  "roles": ["director", "vp"],
  "maxRows": 10
}

Each row has positionStartYear. A revenue operations director left one of my accounts in 2024, and the roster showed a couple of revenue operations leaders who started in 2025. That is who to write to. A VP of inside sales left another account, and nobody holds that title there now, only a manager. The seat was folded or renamed, which is good to know before you write "congrats on the new role".

5. The same check from Claude Code

Every Actor here is also an MCP tool. I pinned only the one I needed:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/profile-lookup" --header "Authorization: Bearer <APIFY_TOKEN>"

Then a Claude Code session with that one tool, shell and file tools switched off, and twenty rows of the test list as CSV: profile URL, company, domain. The prompt without the CSV:

This is an export from our CRM: contacts we sold to or talked to in 2024, with the company we have on file for each.

Before we start sequences again I need to know who still works at the company on file and who moved, and for the ones who moved, where they work now. Use only the Apify MCP tools you have. One paid pass over the list is fine, do not run the same lookup twice. Give me a short table: contact number, still there / moved / unclear, current company, and anything I should double-check by hand.

It ran one lookup over the twenty, read the dataset twice and answered in under two minutes. All ten leavers came back as moved, with the new company and, for most, the month they started there. It did not fall for companyName: it pointed out on its own that the board seat, the community and the advisor title were not the employer. It caught the person with two open jobs and marked them "probably moved", because the headline named the new company. And it flagged two contacts whose job at the company on file had ended before 2024 or right at its start. In a real CRM that means the record was probably wrong the day it was entered.

Three people it left as unclear, and the reason is worth knowing. It asked for compact rows, and a compact row carries a shortened list of positions, so for those three the job at the CRM company was not in it. It said so and asked before paying for a second pass, as the prompt told it to. Next time "use full rows, not compact" goes into the prompt.

Things that bit me

Dates. Every row has updatedAt, the day the record was last refreshed, and on my list most were from this spring. A move after that date does not show up. Compare it with the day the contact entered your CRM: old CRM rows are where this check pays off.
A cost cap on the call. My first API run stopped partway with "stopped at your maximum charge limit" in the status line. The call had a default cap below what the list needed. Set maxTotalChargeUsd yourself or split the list. Nothing past the cap is charged.
A domain that matches two companies. One domain I tried came back ambiguous from Domain to Company. Pick the company by hand, or keep the slug in the CRM next to the domain.
Two open jobs. Covered above, and it happens more than you would think. The start dates decide.

The recipe

Export profile URL (or email), company and company domain from the CRM.
Domain to Company on the domains, keep the slug.
Profile Lookup on the URLs with contacts: true and full rows. Reverse Email Lookup if the address is all you have.
Moved means no open position at the CRM company's slug. Not a different companyName.
For movers: update the record, add the new work address, open the new company as an account.
For the old accounts: Company Employees with the old title, newest positionStartYear first.

Run it before a big campaign, on contacts older than the dates on the rows.

If you want the people who left a customer as a list, rather than checking the CRM you have, Former Employees Finder does it from the domain, and the alumni post shows how. The address side for a list of profile URLs is in the bulk email finder post.

FAQ

Is this a job-change tracker? No. It checks a list against the profiles as they are on record. Run it again in a few months and you get whatever changed on those records since.

Do I pay for misses? No. A URL that matches nobody comes back as a free not_found row, a removed profile as a free profile_removed row.

Does it need my login or a browser extension? No. The answers come from a database, so there are no cookies, sessions or proxies on your side.

If your CRM keeps something I did not cover here, a title history or a deal stage, tell me in the comments and I will try the check on it.

30 ready-made B2B data tasks on Apify, from lead lists to call lists

Kevin Hall — Sat, 31 Oct 2026 05:55:46 +0000

Every B2B data Actor I use on Apify has thirty or forty input fields. That is great for an agent and terrible for a person who opens the page for the first time and just wants a list of HR directors in Ohio

So I saved the combinations people actually ask for as ready-made tasks. A task page shows the input already filled in, the columns you will get and a Try for free button. The button copies the task into your Apify account, you change a field or two and press start

Below are thirty of those jobs, grouped by the problem you walk in with. For each one: the link, the input, what comes back and what to run next. The counts were taken with free previews on 31 October 2026

How to use a task

Open the link, press Try for free, change what you need, press Start. The input on the page is plain JSON, so the same object works from the API, from Make or n8n, and from an agent over MCP.

Two habits save most of the budget. Count first wherever the Actor has a free count or preview. And cap the run with maxResults or maxRows until you like what comes back.

You have an ICP and no list

This is where B2B Leads Finder lives. You describe the people, it returns one row per person, and every row has a live email.

1. Sales leaders at mid-size US companies. Open the task.

{"jobTitles": ["vp sales", "head of sales", "chief revenue officer"], "countries": ["us"], "companySizeMin": 50, "companySizeMax": 1000, "emailType": "any", "maxResults": 100}

Each row brings fullName, jobTitle, email with emailType set to work or personal, the company name, domain, size and industry, location and the profile link. phoneOnRecord tells you for free whether a mobile number exists. People with no live email are skipped and counted in a note row, not charged.

Two fields worth knowing here. maxPerCompany stops one big employer from eating the list. excludeDatasets takes the dataset of last week's run and leaves those people out, so a weekly rerun only brings new names.

2. Small business owners. Open the task. The trick is in one field: "owner" also matches product owners and process owners, so the task excludes them.

{"jobTitles": ["owner", "founder", "ceo"], "excludeJobTitles": ["product owner", "process owner"], "countries": ["us"], "companySizeMin": 1, "companySizeMax": 50, "emailType": "any", "maxResults": 100}

3. Managing directors in Germany. Open the task. Local markets write titles in the local language, so search in it.

{"jobTitles": ["geschäftsführer", "inhaber", "managing director", "ceo"], "countries": ["de"], "companySizeMin": 10, "companySizeMax": 250, "emailType": "any", "maxResults": 100}

4. HR and talent leaders, or procurement managers. Same Actor, different titles. The HR task asks for work addresses only with "emailType": "work", which is what you want when you sell to a company and not to a person. The procurement task adds "industries": ["Manufacturing"] and a seniority floor so buyers come without interns.

5. You already built the search in Apollo. Open the task. Paste the people-search URL into apolloUrl and the Actor reads the filters out of it. No Apollo login and no credits.

6. You need people you can call, not just email. Leads with Phones takes the same filters and only returns people who have both a verified mobile and a live email. Sales leaders with mobiles and real estate agents and brokers are ready to run.

{"jobTitles": ["realtor", "real estate agent", "real estate broker", "broker associate"], "industries": ["Real Estate"], "countries": ["us"], "maxResults": 50}

Rows carry phone in E.164, every number in phones, the email and the company. A skipped_no_contact note row says how many matching people had no mobile or no email. Those cost nothing.

Count before you pay for a single row

People Search has a count mode and a market mode. Neither charges per row, and they answer the question you should ask before any list: how big is this, really.

7. How many software engineers per country. Open the task.

{"mode": "count", "titleKeywords": ["software engineer", "software developer"], "segments": [{"name": "United Kingdom", "countries": ["gb"]}, {"name": "Germany", "countries": ["de"]}, {"name": "Canada", "countries": ["ca"]}]}

One row per segment with _total. Today the UK came back with about 186 thousand, Canada 166 thousand and Germany 116 thousand. The US and India stop at the count ceiling of a million, which tells you to narrow before you pull.

8. Compare sales team size across companies. Open the task. Each segment is a company domain, the titles are account executives, SDRs and sales managers. Handy for sizing a territory or for a competitor slide.

9. Count a Sales Navigator search before exporting it. Open the task. Paste the search URL, get the count, then run the export task with the same URL. The sample search for US heads of growth counted 1,278 people. No seat and no cookies.

Then switch mode to people and you get rows. Two filters people rarely find on their own: onlyBetweenJobs for people with no current position, and careerStartYearMin for engineers early in their career.

You hold profile URLs or emails

The two most used Actors in the family live here. The tasks use placeholder inputs, so replace them with your own list.

10. Profile URLs to mobile numbers. Open the task on Phone Number Finder.

{"profileUrls": ["https://www.linkedin.com/in/jane-doe-example", "jane.example@example.com", "Jane Example, example.com"]}

The field takes profile links, email addresses and "Name, domain" lines in one list, mixed freely. A found row has primaryPhone, all numbers in phones, phoneCount, the name, title, company and location. no_phone, not_found and profile_removed are free rows that tell you why.

11. CRM contacts with an email and no number. Open the task. Same Actor, the list is just emails. Export the column from the CRM and paste it.

12. Profile URLs to work emails. Open the task on Email Finder.

{"profileUrls": ["https://www.linkedin.com/in/jane-doe-example"], "includePersonalEmails": false}

The row gives email, every company address on record in workEmails, and emailType. That last field is the one to read. work_current is an address at today's employer. work_other is an address from somewhere else, usually an old job.

13. Find the CRM contacts who will bounce. Open the task. Same input, different reading. Every work_other row is a contact whose address in your CRM probably points at a former employer. Fix those before the next sequence, not after the bounce report.

14. Personal emails for recruiting. Open the task. Flip includePersonalEmails to true and gmail or outlook addresses come back too, which is what a recruiter needs for someone who should not get a job offer at their work address.

You have a list of companies

Company Employees and Decision Maker Email Finder by Domain both start from a website domain.

15. The leadership team of one company. Open the task.

{"companies": ["hubspot.com"], "roles": ["cxo", "vp", "director"], "titleExcludes": ["assistant", "office of", "executive operations", "chief of staff"], "excludeLowSignal": true, "maxRows": 200}

Rows carry fullName, title, seniority, location, positionStartYear, hasWorkEmail, hasPersonalEmail and the profile link. The titleExcludes list is there because executive assistants love titles like "Office of the CEO".

16. Every employee, then contacts only for the ones you need. The roster task uses "profileDetail": "roster", the light tier, to list the whole company. The contacts task switches to "profileDetail": "contacts" with "mustHave": ["email"], so anyone without an address is skipped for free.

17. Engineers at a company you recruit from. Open the task. titleContains takes engineer and developer, titleExcludes drops sales engineers and solutions engineers.

18. The CEO and founders of a list of companies. Open the task.

{"domains": ["linear.app", "vercel.com", "supabase.com", "posthog.com", "retool.com"], "roles": ["founder", "cxo"], "maxPerCompany": 3}

Rows come ranked per company in _rank, with the title, seniority, profile link and an email that reaches the person today. That means an address on the company domain, else a personal one, never one at a past employer. There are ready versions for marketing leaders and CTOs and engineering leaders.

19. The email format of a domain. Open the task on Company Email Format Finder. Send domains and get pattern like first.last, how many real addresses confirm it, how strongly they agree, and a few masked samples. Useful when you have a name and a company and nothing else.

You want a reason to reach out

A list is cold until something happens at the company. These tasks start from the something.

20. Companies hiring account executives right now. Open the task on Companies Hiring Now.

{"jobTitles": ["account executive"], "locations": ["United States"], "postedLimit": "month", "excludeAgencies": true, "maxCompanies": 25, "decisionMakers": true, "decisionMakerTitleKeywords": ["chief revenue", "head of sales", "vp sales"], "decisionMakersPerCompany": 2}

The free preview counted 3,344 employers with 12,279 matching postings in the last month. Each company row carries matchingJobs, the job titles, jobs30d and jobs90d for the hiring pace, and the company card. With decisionMakers on, the people who own the hire follow as rows of _type decision_maker.

A team hiring five AEs is probably shopping for sales tools too. The engineering version does the same for German companies hiring developers, with the CTO.

21. New senior hires at your target accounts. Open the task on New Hires Finder. New leaders tend to pick their vendors in the first months.

{"companyDomains": ["hubspot.com", "zendesk.com", "asana.com"], "sinceMonths": 12, "seniority": ["director", "vp", "cxo"], "maxPerCompany": 20}

Rows bring startedAt, previousCompany and previousTitle, which is the opening line of the email.

22. Former employees of a company and where they are now. Open the task on Former Employees Finder. Point it at a customer and you find champions who moved to new companies. Point it at a competitor and you find people who already know the problem. leftAfterYear keeps it recent, and each row has currentCompany, currentTitle and currentRoleStartYear.

23. New VPs of sales since last October. Open the task. People Search with currentRoleStartedAfterDate set to 2025-10. Change the titles and you have new CFOs, new heads of people, new anything.

24. Who hires for Kubernetes in Berlin. Open the task on Jobs Database API. It searches the job description, not the title, so a platform engineer posting that mentions Kubernetes counts. Today: 96 open postings at 65 employers, data through 21 October.

{"titleSearch": ["devops engineer", "platform engineer", "site reliability engineer"], "descriptionSearch": ["kubernetes"], "locationSearch": ["Berlin, Germany"], "timeRange": "30d", "removeAgency": true, "previewOnly": true}

Write the city with its country. A bare "Berlin" is refused, "Berlin, Germany" works.

You need companies, not people

25. Seed startups in Europe funded since 2025. Open the task on Company Search.

{"countryGroups": ["eu"], "hasFunding": true, "fundingRounds": ["pre_seed", "seed"], "fundedAfter": "2025-01-01", "employeesMax": 50, "previewOnly": true}

The preview counted 1,650 companies. Turn previewOnly off and each row is a company card: name, domain, headcount, industry, HQ and a funding block with the last round type and date. The Series A and B task and German manufacturers work the same way.

26. Companies like your best customers. Open the task on Lookalike Company Finder. Give it two or three customer domains in seedDomains. Every row says what it matched on in matchedOn, so you can see why a company is there instead of trusting a score.

27. Clean up a column of messy domains. Open the task on Company Enrichment by Domain. It takes https://www.notion.so/product, WWW.GONG.IO and linear.app/features as they come from a spreadsheet and returns one card per domain. When two companies claim a domain, the row says so and costs nothing instead of guessing.

You have a mess to clean

28. Qualify inbound sign-ups by email. Open the task on Reverse Email Lookup. Paste the emails from your sign-up form and get back the person, title and company with "compact": true. Now you know which trial is a VP at a real company and which is a student.

29. Where do your customer contacts work now. Open the task on Profile Lookup. Feed it the profile URLs of the people who signed your contracts. A changed companyName is either a churn risk or a new account, sometimes both.

30. A CRM export with a bit of everything. Open the task on Waterfall Lead Enrichment. Each row of the CSV can carry a different key: an email, a profile URL, a name with a company. The Actor resolves whatever is there to a profile and adds contacts with "contacts": true. For people files there is also Bulk People Enrichment.

Chains that work

One task rarely finishes the job. These are the chains I run most:

Companies Hiring Now for the employers, then the domain column into Decision Maker Email Finder, then the profile links into Phone Number Finder for the ones worth a call.
People Search in count mode to size the box, B2B Leads Finder to pull it, and the same input every Monday with excludeDatasets pointing at last week.
Former Employees Finder on your best customer, then Email Finder on the profile links, and keep only work_current.
Reverse Email Lookup on a new sign-up, Company Enrichment by Domain on the company, Decision Maker Email Finder for the person who signs.

Running them from an agent

Every Actor here is also an MCP tool. Pin the ones you need so the agent does not load the whole Store:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/people-database-search,b2bsearch/company-employees,b2bsearch/linkedin-to-phone" --header "Authorization: Bearer <APIFY_TOKEN>"

The task inputs above are exactly what the agent sends. Ask it to count first and to cap each call with maxResults, and it will usually do both.

FAQ

What does Try for free do? It copies the task into your Apify account with the input filled in. You run it on your own account and can change any field first.

Do I pay for misses? No. A person with no email, a domain nobody claims or a profile that was removed comes back as a free row with a _status that says why.

Does it scrape anything or need my login? No. The answers come from a database, so there are no cookies, sessions or proxies on your side.

Can I use these from the API? Yes. POST the same JSON to the Actor's run endpoint, or run the task by its id.

If the job you have is not on this list, tell me in the comments. The good ones become task number thirty-one.

What $10 buys on Apify in B2B data

Kevin Hall — Fri, 30 Oct 2026 10:07:19 +0000

Apify's free plan comes with five dollars of usage a month and no card; the Starter plan folds nineteen into its fee. Most people spend that on a scraper: minutes of compute, a login, a proxy, a few hundred rows if nothing breaks. Spent on pay-per-result Actors it buys something else: rows, and only rows that answer the question.

This is the map of what $10 buys in B2B data with the b2bsearch Actors, and then, for each one, what you send, what comes back, why the columns matter and which Actor to run next.

The quantities are Starter-plan prices rounded down; on the free plan the same ten dollars is two months of credit and buys about as much, a little less on the leads and phone finders. No hit rates and no benchmarks today; those are in the posts linked along the way.

In one paragraph

b2bsearch on Apify is a family of pay-per-row Actors over one database: 1B+ professional profiles, 115M companies, 50M+ job postings.

A filter, a list of domains, profile URLs, emails or a CSV goes in; a flat table comes out, with emails and phones where they are on record. Misses, counts and repeats are free. No cookies, no login, no proxies, and every Actor is an MCP tool for Claude Code and other agents.

What $10 buys

B2B Leads Finder
4,000 leads, each with a live email

Company Employees
1,100+ employees of your target accounts, with emails and phones

Decision Maker Email Finder by Domain
3,100 founders, C-level and VPs with their emails

Company Search
6,600 companies by industry, headcount, HQ and last round

Company Enrichment by Domain
1,800 company cards for a list of domains

People Search
5,000 people rows from 35+ filters, count and market shape free

Email Finder
1,250 emails at the current employer for profile URLs you hold

Phone Number Finder
900 verified US mobile numbers

Profile Lookup and Bulk People Enrichment
3,100 full career records, or rows of a CSV resolved by any key

Reverse Email Lookup
3,100 people behind email addresses

Companies Hiring Now
4,100 employers hiring for a role, with their hiring pace

Jobs Scraper and Jobs Database API
12,500 job postings with the company card, or 6,200 with the named recruiter and the employer's pace

Misses are free rows on every one of them, so the budget goes to answers, not attempts.

How to make the credit go far

Five habits, all of them free:

Count before you buy. Company Search and the jobs Actors have previewOnly; People Search has mode: "count" and mode: "market". A count tells you the size of a segment, a market run tells you its shape, and neither charges a row.
Let the misses be free. A person with no email, a domain nobody claims, a namesake with five holders: each comes back as a row with a _status and a note, and no charge. Read the notes; they are the autopsy of your list.
Say what a row must have. mustHave (currentWorkEmail, personalEmail, phone, github and so on) means a row without it is skipped free and counted in one note row, instead of delivered and paid for.
Never pay for the same person twice. excludeDatasets on the search Actors takes the datasets of earlier runs and leaves everyone in them out. A weekly rerun costs only the new people.
Cap the run. maxResults, maxRows, maxPerCompany, and callOptions.maxTotalChargeUsd when an agent is doing the calling.

The free plan returns up to a hundred results per run, with a monthly allowance per Actor; counts and previews sit outside it, and any paid plan lifts it. The rows themselves are the same on every plan.

Start from a filter: you have an ICP, not a list

B2B Leads Finder

B2B Leads Finder is the one to open when the brief reads "VPs of sales at US software companies with 50 to 500 people", and the Apollo alternative in the family.

Job titles, seniority buckets, countries or regions (dach, nordics, latam), cities, company size, industries, headline keywords, account domains, past employers, a refresh date. Or paste an Apollo people-search URL and let the Actor read the filters out of it.

{
  "jobTitles": ["vp sales", "head of sales"],
  "countries": ["us"],
  "companySizeMin": 50, "companySizeMax": 500,
  "industries": ["Software Development"],
  "emailType": "work",
  "maxPerCompany": 2,
  "maxResults": 200
}

Every row is a person with a live email: name, title, headline, the address and whether it is work or personal, both when both exist, company name, domain, size and industry, location, the profile URL, X, GitHub and Facebook links where on record, a phoneOnRecord flag (switch on includePhones for the number itself), a stable personId and a _freshness bucket. People without an email are not delivered and not charged; the note rows say how many, and why.

That is a send-ready list, and the reason the family exists. Next: excludeDatasets for next week's delta, Profile Lookup when you want the whole career behind a lead, Phone Number Finder for the call list. The deep dive: Apollo alternative in Claude Code: 7 lead lists from one Apify Actor.

People Search

People Search is the same database with every filter exposed, 35+ of them. Title and headline keywords with AND lists, seniority, employer domains, industries and headcount, employer HQ country, past employer and the year they left, past titles, career start year, tenure, city, languages, connection count, people between jobs, records refreshed after a date.

Three modes. count answers with one number. market answers with the shape, countries, seniority, employer size, industries, top titles, top employers, how many have a personal or a work address, one row per bucket; segments compares up to ten variants in one run. people returns the rows at the tier you choose: row (name, title, employer, location, email flags), profile (the career record) or contacts (plus emails and phones), with compact for agents.

This is where the signals live: who left a competitor since last year (pastEmployerDomains plus leftPastEmployerAfterYear), who started a role this quarter (currentRoleStartedAfterDate), fractional execs by headline. Two worked examples: the warmest cold list, people who left one company since 2025 and fractional CFOs by headline.

Company Search

Company Search builds the account list: countries or groups, industries (a sector covers everything under it), HQ city or state, founding year, headcount band, and funding: hasFunding, last round after or before a date, the stage of the last round, the amount. previewOnly: true first.

{
  "countries": ["gb"],
  "industries": ["Financial Services"],
  "hqLocations": ["London"],
  "employeesMin": 51, "employeesMax": 200,
  "fundedAfter": "2024-01-01",
  "previewOnly": true
}

A company row: name, primary domain, website, company page URL, headcount, industry with its taxonomy id, last round type, date and amount, founding year, description, country and HQ. Unknown facts are left out, never shipped as empty strings; a company the store holds twice comes back once, the duplicate as a free row.

The domain column is the handle for everything below: paste it into Company Employees, Decision Makers or Lookalike Company Finder.

Companies Hiring Now

Companies Hiring Now turns a job search into the employers behind it. Job titles as boolean lines ("account executive" OR "sales development"), countries, states or cities, how far back, experience level, employment type, industries, agencies out. Turn on decisionMakers with roles, a per-company cap and title keywords, and each employer comes with the people who own the budget.

One row per employer: the company card (domain, industry, headcount, country, HQ, funding), how many postings matched and how many are still open, first and last posting dates, open postings in total, postings in the last 7, 30 and 90 days, the seniority mix and the most posted titles of the last month.

Then one row per decision maker: name, title, seniority, profile URL, freshness.

A company hiring three account executives this month has a sales budget and a sales leader under pressure. That is a better trigger than any firmographic. Next: Company Employees for the rest of the team, Email Finder for the addresses.

Jobs Database API

Jobs Database API is the posting-level search over 50M+ job postings from the last 180 days. Boolean title and description search with exclusions, location, employer size and industry, agencies out.

Then seniority, employment type, salary stated or above a floor, an applicant-count ceiling, posted after a date, open or expired, and the people behind the job: the named recruiter, the employer's hiring pace, the employer's decision makers. previewOnly gives the market breakdown free; compact keeps rows short.

A job row: title, URL, posted date, the company card, location, seniority, employment type, salary text and parsed range, applicant range, recruiter name and profile URL, the employer's open postings and 7, 30 and 90-day pace with its top titles, whether the posting is still open and until when, the description as text or markdown.

Recruiters use it for market maps, sales teams for "who just posted for the role my product replaces", developers for a job search without the duplicates. Two posts came out of it: half of US backend postings were copies and ghost jobs, measured.

Start from domains: you have the accounts

Company Enrichment by Domain

Company Enrichment by Domain takes a column of websites in any form (acme.com, a URL with a path, www) and returns one card per domain: company name, company page URL, website, industry, headcount and range, country, HQ city and region, founding year, description, last funding round with date and amount.

{ "domains": ["acme-robotics.com", "https://www.northwind-logistics.co.uk/about"] }

Three statuses. found is the card. not_found means no company lists this domain as its site, free. ambiguous means several unrelated pages claim it, or it is a shared host like github.io, also free, and never a guess. Use it to qualify inbound (a form fill with a company domain becomes a size, an industry and a funding stage in one call), to clean a CRM, or to feed the two Actors below.

Decision Maker Email Finder by Domain

Decision Maker Email Finder by Domain answers the question every account list ends with: who runs this place. Domains in, up to five hundred per run, roles to pick from founders, C-level, VPs and directors, maxPerCompany in rank order, titleKeywords to keep only marketing, finance or engineering.

A row per person: rank, company name and headcount, full name, job title, seniority bucket, headline, profile URL, location, in-role-since year, email flags, and email with its type: a work address on the company's own domain when one reaches the person today, else a personal one, at no extra charge. A domain with nobody on record comes back free, with a hint about brand domains.

This is the ten-accounts-by-Friday Actor. Next: Phone Number Finder on the profile URLs for the call list, Company Employees when you need the layer below the leadership.

Company Employees

Company Employees is the org map. Domains in, and profileDetail decides the depth: roster for the staff list (name, title, seniority, headline, city, email flags, profile URL, freshness stamps), profile for the career record of each person, contacts for emails, phones and social links. roles keeps seniority buckets, titleContains and titleExcludes pick departments, mustHave keeps only people you can reach, excludeLowSignal drops self-declared profiles, compact keeps rows short for agents.

{
  "companies": ["acme.com"],
  "roles": ["vp", "director"],
  "titleContains": ["sales", "revenue"],
  "profileDetail": "contacts",
  "mustHave": ["email"],
  "compact": true
}

Why the roster first: it is the cheapest tier and it carries hasWorkEmail and hasPersonalEmail per person, so you can pick the twelve people who matter and send only those to the contacts tier or to the Email Finder.

A repeat of an employee already delivered never charges, so re-running an account next month costs only the new hires. Full walk-through: account mapping by company domain.

Start from people you already have

Email Finder

Email Finder takes profile URLs or bare handles, up to a thousand per run, and returns the addresses on record, never a pattern guess.

Each row is labelled: work_current for the current employer's domain, work_other for an older company address, personal when includePersonalEmails is on, with the whole workEmails list and a count. A profile with nothing on record is a free no_email row that still names the person and says when a personal mailbox exists.

The labels are the product. A list of two hundred URLs becomes three piles, send now, verify first, skip, in one run: bulk email finder in Claude Code. For the "verify first" pile, Work Email Finder takes name plus domain, ranks candidates and checks the best one against the mail domain.

Phone Number Finder

Phone Number Finder accepts a profile URL, an email, or "Jane Smith, acme.com" per line, up to 20,000 a run, and returns verified mobile numbers: direct dials, never a switchboard, with name, title, company, location and a _freshness bucket.

A known profile without a number is a free no_phone row. It is US-centric by design, so run it on US rows and expect little elsewhere. The call-list recipes: Lusha and ZoomInfo alternative in Claude Code.

Profile Lookup and Bulk People Enrichment

Profile Lookup is the full record for a list of profile URLs: headline, current title and company, location, industry, connection count, tenure and total experience in years, every position with dates and descriptions, education, skills, languages, certifications, patents and publications when the profile has them, updatedAt for the record's age, and with contacts on, the emails and phones.

It also reads the input names other profile scrapers use (urls, publicIdentifiers), so an existing integration only changes the Actor id.

Bulk People Enrichment is the same record for a CSV of up to 50,000 rows, each resolved by the strongest key it carries: email, profile URL, GitHub, X or Facebook handle, or a full name with a company domain. Namesakes come back as a free ambiguous row with the holder count, never a guess, and rows stream into the dataset as they resolve.

This is the fifty-columns pair, and the reason to pull the full record even when you only need a name: once the table is on your machine you can filter by anything in it. More on that below.

From an email, a name or a handle

Reverse Email Lookup turns any email into the person's full career row.

Email to Profile Finder is the lighter version: profile URL, name, headline, title, company and location, with a name beside a work address to find more. Name to Profile resolves "Jane Smith, acme.com" to the profile and career.

Social Handle Lookup does the same from a GitHub, X or Facebook handle. All four: an invalid or unmatched entry is a free row that says so.

The rest of the family, one line each

You hold	Actor	You get
a Sales Navigator search URL	Sales Navigator Search	the people the search describes, count first, no cookies or seat
a filter box and calls to make	Leads with Phones	leads where every row has a verified mobile and a live email, the Lusha alternative
a competitor's domain	Former Employees Finder	alumni, when they left, where they are now
your target accounts	New Hires Finder	who joined in the last months, with title, start month and seniority
three good customers	Lookalike Company Finder	similar companies by industry, country and size, each row with its match reason
a domain and no name	Company Email Format Finder	the real address pattern, from addresses on record
a messy CSV	Waterfall Lead Enrichment	whatever key each row carries, resolved to a profile with contacts, the Clay alternative
a job search	Jobs Scraper	postings in bulk with the full description and the company card
personal emails	Email to Company	the employer and title behind a gmail address
emails or handles	Email to Phone, Name to Phone, the Facebook and X doors	the same person, from the key you have

Work the table on your machine

Every run writes a dataset, and a dataset exports as JSON, CSV or XLSX from the Console or from one URL:

https://api.apify.com/v2/datasets/<DATASET_ID>/items?format=csv&clean=true&token=<APIFY_TOKEN>

Pull the profile tiers and you have fifty-plus columns per person: every position with dates, the employer card behind each one, education, skills, languages, email flags, freshness. That is where the "exactly the leads you need" part happens, after the pull and for free: people who were at a competitor before this job, who started this year, whose record was refreshed since spring, who list a language your rep speaks. One query over the CSV in DuckDB, a filter in Sheets, a WHERE in pandas.

SELECT fullName, jobTitle, companyName, email
FROM 'leads.csv'
WHERE emailType = 'work' AND _freshness IN ('fresh_90d', 'updated_1y')

Join on companyDomain to the company cards, dedupe on personId, and feed the survivors to the next Actor by their profile URL. The database answers in seconds; the thinking happens locally, on columns you paid for once.

Four combinations worth stealing

Hiring signal to inbox. Companies Hiring Now (the titles your product serves, agencies out, decision makers on), then Company Employees (roles: ["vp", "director"], titleContains for the function), then Email Finder on the rows you picked.
Inbound in one minute. Email to Profile Finder on the form-fill address, Company Enrichment by Domain on its company domain, Decision Maker Email Finder for the two people above the one who filled the form. The write-up.
Competitor alumni. People Search with pastEmployerDomains and leftPastEmployerAfterYear, market first to see where they went, then people with mustHave: ["email"].
CRM refresh. Bulk People Enrichment on the CRM export; rows whose current employer no longer matches the CRM, or whose updatedAt is old, are the ones to re-check, and Company Employees on the old domain tells you who replaced them.

Wiring: Claude Code, MCP, REST, n8n

Pin the Actors you use in the server URL, so an agent loads only those definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/people-database-search,b2bsearch/company-database-search,b2bsearch/domain-to-company,b2bsearch/domain-to-decision-makers,b2bsearch/company-employees,b2bsearch/linkedin-email-finder,b2bsearch/linkedin-to-phone,b2bsearch/hiring-companies-finder,b2bsearch/linkedin-job-search-api" --header "Authorization: Bearer <APIFY_TOKEN>"

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/company-employees,b2bsearch/domain-to-company",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen (b2bsearch--company-employees). Any Actor is also one REST call that returns the rows in the response:

curl -X POST "https://api.apify.com/v2/acts/b2bsearch~domain-to-decision-makers/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["acme.com"], "roles": ["founder", "cxo"], "maxPerCompany": 3}'

And a step in n8n, Make and Zapier through the Apify integrations, or a tool in LangChain, CrewAI and the OpenAI Agents SDK through the same MCP server.

FAQ

Is any of this scraped when I run it? No. The Actors answer from a database of publicly available professional data; nothing is crawled at run time, and no account of yours is involved.

Which Actor first? A filter: B2B Leads Finder for people, Company Search for accounts. A domain: Company Enrichment by Domain, then Decision Makers or Company Employees. URLs, emails, names or a CSV: the finders and Bulk People Enrichment. A job title: Companies Hiring Now.

What happens on a miss? A free row with _status and a note. Not found, no email, ambiguous domain, namesake, skipped by mustHave: each has a name, and none is charged.

How fresh is the data? Rows carry _freshness and updatedAt, and the search Actors take updatedAfter. It is a database, so a record can be months old, and it tells you when.

Does the free plan get the same rows? Yes, with a cap per run and a monthly allowance per Actor; counts and previews are outside both.

For AI agents reading this

The b2bsearch Actors run as tools over the hosted Apify MCP server with the tools pinned in the URL (above). Pick by the key the user holds:

filters: b2bsearch--b2b-leads-finder, b2bsearch--people-database-search (mode: "count" first), b2bsearch--company-database-search (previewOnly: true first)
domains: b2bsearch--domain-to-company, b2bsearch--domain-to-decision-makers, b2bsearch--company-employees (compact: true)
profile URLs: b2bsearch--linkedin-email-finder, b2bsearch--linkedin-to-phone, b2bsearch--profile-lookup
emails: b2bsearch--email-to-linkedin, b2bsearch--reverse-email-lookup; a CSV: b2bsearch--bulk-people-enrichment
job titles: b2bsearch--hiring-companies-finder, b2bsearch--linkedin-job-search-api (previewOnly: true first)

Every row has _status; rows other than found are free and explain themselves in _note or _error. Read results with get-dataset-items and a fields list. Set callOptions.maxTotalChargeUsd on every paid run; per-plan pricing is on each Actor page. Platform docs: Apify MCP server and apify.com/agents.md.

B2B data API for AI agents: 7 Apify Actors I use in day-to-day tasks

Kevin Hall — Fri, 30 Oct 2026 08:45:20 +0000

Most of my week is lists. Someone sends a filter, a pile of domains or a column of profile URLs, and wants people with a working address on the other side. The question that comes with it is always the same: which one do I run.

This is the answer I now send back. Seven Actors on Apify, all reading one database of professional profiles and companies: links, what each one takes and returns, what I measured on them on 30 October, and how an AI agent calls them over MCP.

If your last week included a 403 page, a CAPTCHA, or a scraping account that stopped working, start with the next section. It explains why these are lookups and not scrapes.

In one paragraph

The b2bsearch Actors on Apify are a B2B data API over a database of 800M+ professional profiles and 115M companies. Filters, domains, profile URLs or emails go in; leads, employees, company cards, emails and phone numbers come out. Nothing is scraped at run time, misses and counts are free, and every Actor is an MCP tool for Claude Code and other agents.

Why a database and not a scraper

Most listings in this corner of the Store are live scrapers. They need a session cookie or a login, they run through proxies, a run takes minutes, and when the site answers 403 or 429 the scraper retries or stops. The account carrying the risk is yours.

Pricing follows the same logic. Many charge per returned row whether or not the row has what you asked for. Some add a start fee per run, a minimum budget per run, or a lifetime run cap for free accounts.

I read 86 listings in this category in October: about a third have a hard limit for free users and 16 charge a start fee of a cent or more.

The seven Actors below answer from a database. No cookies, no login, no proxies, and a run finishes in seconds. The things that are never charged are the part I would defend anywhere:

Never charged	How you see it
a miss	a free row with `_status` and a note saying why
a count or a market breakdown	`previewOnly` or `mode: "count"`
a repeat of a person already delivered	`excludeDatasets`, or inside the same run
a row that fails your `mustHave`	one free note row with the number skipped

Two honest limits. A database lags a live page: rows about people carry a refreshed-on stamp and a _freshness bucket, and the people and leads searches take updatedAfter, so you can insist on fresh records and pay only for those.

And on price I will not claim the cheapest in every niche. In some of them a listing with more users charges less per row; on company search and company employees these sit below the category leader on every plan. The list of what is never charged is where they differ most.

The seven, by what you hold

You hold	Run	You get
a filter box (industry, country, size, funding)	Company Search	companies, with a free count first
a website domain	Company Enrichment by Domain	the company card
a website domain	Company Employees	the roster, full profiles, or people with contacts
a filter box or an Apollo URL	B2B Leads Finder	people with a live email
profile URLs	Email Finder	addresses on record, labelled
profile URLs, emails or names	Phone Number Finder	verified mobile numbers
email addresses	Email to Profile Finder	the person and their profile

How to read the sections below

Every section starts the same way: the Actor link, a short overview, what it takes (the filters that matter) and what it returns. Then come scenarios you can repeat, each with the exact input and a table of the fields that come back.

All runs are from 30 October 2026. They go through the same three addresses, so one example is enough to learn the pattern:

Address	Looks like
Store page	`https://apify.com/b2bsearch/<slug>`
REST endpoint	`https://api.apify.com/v2/acts/b2bsearch~<slug>/run-sync-get-dataset-items?token=<APIFY_TOKEN>`, POST the input JSON as the body
MCP tool	`b2bsearch--<slug>` on `https://mcp.apify.com?tools=b2bsearch/<slug>`

The slug is the last part of the link in each section's first line. The headline segment, where I use one, is fintech companies in London with 51 to 200 employees that raised a round since January 2024. Everything else is a fresh example you can paste.

1. Company Search: filters to companies, count first

Company Search · slug company-database-search

You give it a filter box and it returns company rows. The first call should always be a free count: previewOnly: true answers with the size of the segment and charges nothing.

Takes (the filters that matter):

countries, or countryGroups such as dach, nordics, eu, gcc, latam
industries and hqLocations (city or state)
employeesMin and employeesMax, foundedFrom and foundedTo
hasFunding, fundingRounds (seed, series_a and on), fundedAfter, fundingAmountMin
companyDomains to look up a known list, previewOnly, maxResults

Returns: one row per company.

Field	What it holds	Why it helps
`name`, `domain`, `website`	the company and where it lives online	the key you feed into every other Actor
`linkedinUrl`	the company page URL	a stable id for joins
`employeeCount`, `industry`, `founded`	size, sector, founding year	segment and prioritise offline
`hq`, `countryCode`	headquarters place	route by region
`funding`	last round type, date and amount	"raised a Series A in 2025" is a filter, not research
`description`	what the company says it does	a line for an opener or an LLM prompt

Scenario A: Series A software companies in Germany

Count first, free:

{
  "countries": ["de"],
  "industries": ["Software Development"],
  "fundingRounds": ["series_a"],
  "fundedAfter": "2025-01-01",
  "employeesMin": 20,
  "employeesMax": 200,
  "previewOnly": true
}

One row back in 4 seconds: 16 companies match. Swap previewOnly for "maxResults": 5 and the same call returns five company rows in 5 seconds, each with its round type, date and, when it is public, the amount.

Scenario B: a whole region with one word

countryGroups: ["dach"] stands for Germany, Austria and Switzerland, so one input covers three markets:

{
  "countryGroups": ["dach"],
  "industries": ["Financial Services"],
  "employeesMin": 11,
  "employeesMax": 50,
  "hasFunding": true,
  "previewOnly": true
}

Free answer: 236 companies. If that is too many, add fundingRounds or a city before you pay for a single row.

Scenario C: the headline segment

{
  "countries": ["gb"],
  "hqLocations": ["London"],
  "industries": ["Financial Services"],
  "employeesMin": 51,
  "employeesMax": 200,
  "fundedAfter": "2024-01-01",
  "maxResults": 20
}

Step	Result
count, free	79 companies
rows pulled	20, largest first
run time	about 5 seconds

The trap is headcount: about half of all companies on file carry none, and a size filter drops them unless you switch on includeCompaniesWithoutHeadcount. For a funded fintech list that is fine. For long-tail segments, run the count both ways.

2. Company Enrichment by Domain: one domain, one card

Company Enrichment by Domain · slug domain-to-company

The simplest Actor in the family and the one where agents outnumber humans in my request logs. A list of domains in, a company card per domain out.

Takes: one input, domains, a list of site domains.

Returns: a card per domain.

Field	What it holds	Why it helps
`companyName`, `domain`, `website`	identity	clean up a CRM column
`linkedinUrl`	the company page URL	join key
`employeeCount`, `employeeRange`	headcount and its bucket	route small accounts and big ones differently
`industry`, `description`	sector and a plain-language line	tag accounts without reading sites
`country`, `hqLocality`, `hqRegion`	where the headquarters is	territory routing
`founded`	founding year	age as a signal
`hasFunding`, `lastRoundType`, `lastRoundDate`	funding state	"has money" in one column

Scenario A: three domains, three cards

{ "domains": ["stripe.com", "wise.com", "notion.so"] }

Three cards in 8 seconds, each with a headcount, a sector and a funding flag.

Scenario B: what it does when it is not sure

I sent the eight domains from the London list in Company Search. Six came back as cards. Two came back as ambiguous, each with a note that two unrelated company pages list that domain and neither carries its name, and no charge. A guessed card would have cost more than a free "I do not know".

Scenario C: sort a column of form fills

Drop the domain part of every address on your sign-up list into domains, dedupe first, and read employeeRange and hasFunding. You get the account behind each form fill without opening a tab. The full inbound version is inbound lead qualification from the email domain.

3. Company Employees: the roster, the profiles, or the people you can write to

Company Employees · slug company-employees

The account-based door. One company domain per line, and profileDetail picks how much each person row carries. Everything that narrows the list runs before anything is charged.

Takes:

companies: domains, one per line
profileDetail: roster (staff list), profile (career record) or contacts (adds emails and phones)
roles: cxo, founder, vp, director, manager, other
titleContains and titleExcludes
mustHave: email, workEmail, currentWorkEmail, personalEmail, phone, github, twitter, facebook
compact: true for agents, maxRows to cap

Returns: one row per person, wider with each tier.

Tier	Adds	Use it for
`roster`	name, title, seniority, location, headline, start year, connections, flags `hasWorkEmail` and `hasPersonalEmail`, profile URL	building the org chart and picking who to look up
`profile`	everything above plus `about`, `positions`, `education`, `skills`, `interests`, `industry`, `followersCount`	research before a call, personalisation
`contacts`	everything above plus `email`, `emailType`, `workEmails`, `personalEmails`, `emailCount`, `employerMatch`, `socialLinks`	the send list

Scenario A: who runs this company

{
  "companies": ["stripe.com"],
  "roles": ["founder", "cxo"],
  "profileDetail": "roster",
  "compact": true,
  "maxRows": 5
}

Five people in 4 seconds with title, seniority and the two email flags. The sixth row is a free note, skipped_row_budget, telling you more people matched and maxRows cut the list.

Scenario B: the sales leaders of one company, with an address

{
  "companies": ["wise.com"],
  "titleContains": ["head of sales", "sales director"],
  "profileDetail": "contacts",
  "mustHave": ["email"],
  "compact": true,
  "maxRows": 5
}

Four people in 6 seconds, each with an address, its label and the profile. People without an address are skipped for free and counted in one note row.

Scenario C: leaders across a list of accounts

I ran the two largest companies from the London list twice.

Run	Delivered	Skipped, free	Time
roster, compact rows	25 rows	the rest of the roster, one note row	8 seconds
leaders (C-level, VP, founder, director) with an address on record, contacts tier	20 people	9 without an address, one note row	13 seconds

Of the 20 leaders, 12 came with a company address and 7 with a personal one. The row says which tier it could actually answer: _detail reads contacts when a contact reaches the person today and profile when it does not, and the price follows the row, not the request.

Scenario D: read before you write

Take companies: ["wise.com"], roles: ["founder", "cxo"], "profileDetail": "profile", "compact": true and "maxRows": 3. Three rows come back in 5 seconds with about, positions, education, skills and followersCount. That is enough context for an LLM to draft an opener that mentions something real.

Two more notes. A repeat of an employee already delivered never charges, so re-running a domain next month costs only the new people. And compact: true is the switch for agents: the compact contacts row was about a third the size of the full one in my run, with the same identity, role, five latest positions and contact fields.

The listing prices this Actor below the category leader on every Apify plan. That is a Store fact, not a promise from me; the pricing tab has the per-plan numbers.

4. B2B Leads Finder: a filter box, people with a live email

B2B Leads Finder · slug b2b-leads-finder

The Apollo alternative in the family. You describe the people; every delivered lead has an email at their current employer or a personal one, plus the profile and social links. People who fail the test are not sold: they come back as free note rows with a count.

Takes:

jobTitles, excludeJobTitles, titleMatch (substring or word), seniority
countries, countryGroups, cities, companyHqCountries
industries, companySizeMin and companySizeMax, keywords
companyDomains for named accounts, pastCompanyDomains for alumni of a company
emailType: any, work or personal; includePhones
maxPerCompany, excludeDatasets, updatedAfter, apolloUrl instead of all of the above

Returns: one row per lead.

Field	What it holds	Why it helps
`fullName`, `firstName`, `lastName`, `jobTitle`, `headline`	the person and what they say they do	merge fields and a sanity check
`email`, `emailType`, `workEmail`, `personalEmail`	the address and which kind it is	send to work, hold personal
`phone`, `phones`, `phoneOnRecord`	mobile numbers when asked for	the call list
`companyName`, `companyDomain`, `companySize`, `companyIndustry`	the employer	account-level routing
`location`, `countryCode`	where the person is	time zone and language
`linkedinUrl`, `twitterUrl`, `facebookUrl`	profiles	research links
`updatedAt`, `_freshness`	when the record was refreshed	refuse stale rows

Scenario A: marketing heads at mid-size software companies

{
  "jobTitles": ["head of marketing", "vp marketing"],
  "countries": ["us"],
  "industries": ["Computer Software"],
  "companySizeMin": 51,
  "companySizeMax": 200,
  "emailType": "work",
  "maxPerCompany": 1,
  "maxResults": 10
}

Result	Count
leads delivered	10
skipped free: no work address at the current employer	13
skipped free: had left the role the search matched	5

About 20 seconds. The skipped rows are the feature: the Actor reads the profile, sees the position is closed, and says so in a note row instead of selling you a dead lead.

Scenario B: alumni of a company you compete with

pastCompanyDomains finds people who used to work somewhere. Sales leaders in the DACH region who left a big CRM vendor:

{
  "jobTitles": ["sales director", "vp sales"],
  "countryGroups": ["dach"],
  "pastCompanyDomains": ["salesforce.com"],
  "emailType": "work",
  "maxResults": 5
}

Five leads in 19 seconds, 11 skipped for no work address and 11 more because they had already moved on. These are people who know the tool you replace, which is the warmest cold list I know how to build.

Scenario C: leads with a mobile number

{
  "jobTitles": ["vp sales", "chief revenue officer"],
  "countries": ["us"],
  "industries": ["Computer Software"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "emailType": "work",
  "includePhones": true,
  "maxPerCompany": 1,
  "maxResults": 10
}

Ten leads in 17 seconds, 4 of them with a mobile on record. The phone sits in the same row as the email, so there is no second lookup.

Scenario D: the headline segment, sized first

Before pulling I size the people box for free on People Search with mode: "count". Sales leaders at London fintechs of this size: 231 people. mode: "market" then shows the shape, seniority, employer size and the title spellings in use, also free. The pull itself, work addresses only and one lead per company:

Result	Count
leads delivered	20
skipped free: no work address at the current employer	40
skipped free: had left the role the search matched	33
skipped free: over the one-per-company limit	1

Scenario E: only the new people next week

Pass the dataset id of last week's run in excludeDatasets and rerun the same search. Everyone already delivered is left out and never charged again.

I wrote a whole post on the dead rows: 243 of 417 leads in a typical ICP box were dead before the first email. Built the search in Apollo? Paste its URL into apolloUrl; a Sales Navigator saved search has a twin that takes the URL: Sales Navigator alternative in Claude Code.

5. Email Finder: profile URLs to addresses on record, labelled

Email Finder · slug linkedin-email-finder

You hold profile URLs, you want addresses. It returns the addresses in the person's record, never a pattern guess.

Takes:

profileUrls: full URLs or bare handles, up to 1,000 per run
includePersonalEmails: off by default

Returns: one row per profile.

Field	What it holds	Why it helps
`email`	the best address on record	the one to send to
`emailType`	`work_current`, `work_other` or `personal`	the label that keeps dead addresses out
`workEmails`, `personalEmails`, `emailCount`	every address on record	fallbacks
`fullName`, `jobTitle`, `companyName`, `companySlug`	who and where	merge fields
`location`, `countryCode`, `_freshness`	place and record age	filter

Label meaning: work_current is an address on the current employer's domain, work_other is a company address it cannot tie to the current employer, personal shows up only when you switch the flag on. A no_email row is free and still carries the name, title and employer; a not_found row is free too.

Scenario A: addresses for a list you already hold

{
  "profileUrls": ["satyanadella", "jane-doe-example"],
  "includePersonalEmails": false
}

I fed it the 10 profile URLs from the marketing-leads pull above with personal mailboxes switched on. All 10 came back as work_current in 4 seconds. That is the point of starting from a leads search: the profile URL is a by-product of the pull.

Scenario B: a roster with a hit rate

The 20 roster rows from the Company Employees run went in: 13 came back with a company address, 7 as free rows, 2 of those with a note that a personal mailbox is on record. About 5 seconds.

The labels matter more than the hit rate. On a 200-URL list of marketing leaders earlier this week, about half of the addresses on record were at an older employer, and the label is what kept them out of the send list. That run is here: Bulk email finder in Claude Code: 200 profile URLs, 64 still current.

6. Phone Number Finder: verified mobile numbers, pay per found

Phone Number Finder · slug linkedin-to-phone

Direct dials, not switchboards. It is built to take whatever you already have and find the mobile.

Takes: profileUrls, one entry per line, up to 20,000 per run. Each line can be a profile URL or handle, an email address, or a name plus domain like Jane Smith, acme.com.

Returns: one row per entry.

Field	What it holds	Why it helps
`primaryPhone`	the best verified mobile	dial this one
`phones`, `phoneCount`	every number on record	fallbacks
`fullName`, `jobTitle`, `company`	who it belongs to	check before dialling
`location`, `country`, `linkedinUrl`	place and the matched profile	join back to your list

A miss is a free no_phone row. It is US-centric, by the listing's own words and in my runs.

Scenario A: a mobile for each US lead

I sent the 10 US marketing leads from section 4 by profile URL:

{ "profileUrls": ["https://www.linkedin.com/in/<handle>", "<handle>"] }

Three came back with a mobile, seven as free no_phone rows, in 6 seconds.

Scenario B: the same people, by email

Same 10 people, but the input is their work addresses, one per line. Same result: 3 numbers, 7 free rows. This is the version for a CRM export that has addresses and no profile links.

Scenario C: names and domains only

{ "profileUrls": ["Jane Smith, acme.com", "Raj Patel, example.org"] }

Use it when all you have is a name and a company. I did not run this form today; it is in the listing's input description.

Earlier this week a hundred US sales leaders gave a mobile for 35 of them, chief revenue officers about half, directors one in four. My London roster gave almost nothing, and the misses cost nothing. Run it on US rows. The full call-list recipe is in Lusha and ZoomInfo alternative in Claude Code.

7. Email to Profile Finder: an address in, the person out

Email to Profile Finder · slug email-to-linkedin

The inbound door. It turns email addresses, work or personal, into the person.

Takes: emails, one address per line, up to 1,000 per run. Put a name beside a work address to find more: Jane Doe <jane@acme.com> or jane@acme.com, Jane Doe.

Returns: one row per address.

Field	What it holds	Why it helps
`fullName`, `headline`, `jobTitle`	who they are and what they do	qualify the sign-up
`company`, `companyLinkedinUrl`	the employer and its page	feeds Company Enrichment by Domain
`linkedinUrl`	the matched profile	feeds Email Finder and Phone Number Finder
`location`, `country`	place	routing
`matchedEmail`, `matchedVia`	which address matched and how	audit trail

Addresses it cannot match, invalid ones and duplicates come back as free rows that say why.

Scenario A: a column of work addresses

{ "emails": ["jane@acme.com", "Jane Doe <jane@acme.com>"] }

Ten work addresses from the leads pull went in and 10 people came out, every one matchedVia: as_given, in 6 seconds.

Scenario B: close the loop

The 13 addresses the Email Finder returned for the London roster went back in. 13 people came out, and all 13 were the profiles the roster started from. About 6 seconds.

Scenario C: a form fill becomes an account

A visitor leaves an address. Run it here, take companyLinkedinUrl or the domain into Company Enrichment by Domain, then Company Employees for the decision makers next to them. That is the inbound chain in inbound lead qualification from the email domain.

How they chain

You start with	Chain	You end with
a market idea	Company Search count, then rows, then Company Employees	named people at named accounts
a filter box	B2B Leads Finder with `includePhones`	email plus mobile in one row
a list of profile URLs	Email Finder, then Phone Number Finder on the misses	the best reachable channel per person
a sign-up list	Email to Profile Finder, then Company Enrichment by Domain	the account behind each address
last month's list	B2B Leads Finder with `excludeDatasets`	only the new people

What does an agent pay to load all seven?

An MCP tool costs tokens before it is called: the description, the input schema and the output schema the server infers from rows. I measured tools/list on the hosted Apify MCP server with the seven pinned, tiktoken o200k on compact JSON.

Tool	Tokens
Company Employees	4,191
B2B Leads Finder	3,990
Company Search	3,344
Email Finder	2,016
Phone Number Finder	1,961
Email to Profile Finder	1,955
Company Enrichment by Domain	1,953
four helper tools (run, abort, dataset, key-value store)	3,812
total	23,222

For scale: two days ago I measured 20 job Actors the same way and got a median of 3,829 per tool, with one at 32,737. The seven here sit at a median of 2,016.

The descriptions are 80 to 97 tokens each; the weight is in the input schemas of the search Actors and in the inferred output schema of Company Employees. Flat rows keep that schema small, and compact: true keeps the rows small after the call.

Method and the job numbers: MCP tool cost: 20 job Actors on Apify.

Wiring: Claude Code, MCP, n8n, REST

Pin the Actors in the server URL so an agent loads only these definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/company-database-search,b2bsearch/domain-to-company,b2bsearch/company-employees,b2bsearch/b2b-leads-finder,b2bsearch/linkedin-email-finder,b2bsearch/linkedin-to-phone,b2bsearch/email-to-linkedin" --header "Authorization: Bearer <APIFY_TOKEN>"

The same server in any MCP client (Cursor, Windsurf, Claude Desktop, ChatGPT, LangChain, CrewAI, the OpenAI Agents SDK):

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/company-database-search,b2bsearch/domain-to-company,b2bsearch/company-employees,b2bsearch/b2b-leads-finder,b2bsearch/linkedin-email-finder,b2bsearch/linkedin-to-phone,b2bsearch/email-to-linkedin",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen: b2bsearch--company-employees, b2bsearch--b2b-leads-finder, and so on. Cap a run with callOptions.maxTotalChargeUsd, read rows with get-dataset-items and a fields list, and run the free count before the paid pull.

Without an agent: every Actor is a REST endpoint. One call, rows back in the response:

curl -X POST "https://api.apify.com/v2/acts/b2bsearch~domain-to-company/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["acme.com", "example.org"]}'

The same Actors are steps in n8n, Make and Zapier through the Apify integrations, and the Store page of each one has the input schema, the output example and the per-plan price.

What the agent did on its own

I gave a Claude Code session the seven tools pinned and a brief: size the segment, pull ten companies, get the leadership of the two largest with a current work email, fall back to the email finder where that fails, cap every paid run, report a ledger. Shell and file tools were denied. Eleven turns, about four minutes, four Actor runs.

What it did without being told:

loaded all seven tool definitions first, then wrote a cost table from the descriptions before the first paid call, naming the tools it would not use
added hasFunding: true and sort: "employee_count_desc" to the company search; its free count matched mine, 79
read rows with a fields list that left out description, the longest field on a company card
added titleExcludes for assistants, "office of" and chiefs of staff to the leadership pull, after reading the field description that warns the C-level bucket catches them
noticed that callOptions is in no Actor's schema and passed the spend cap anyway, in the call options of the MCP server

Where it stopped. It asked Company Employees for leaders with an address at the current employer, exactly as briefed, and both runs came back as one free note row each: the leaders on record did not carry one, so nothing was delivered and nothing charged. With no profile URLs in hand it skipped the email finder, handed over the account list with a trust column (two rows marked questionable, one not fintech by its industry, one to check for HQ) and stopped.

That is the behaviour I want from an agent spending money. It is also a brief bug: step three should pull the cheap roster first and run the finder on its URLs. With the requirement loosened to any address on record, the same two companies gave 20 people in my own run above.

What this does not do

It does not read a live page. A row can be months old; the stamp is on rows about people, and updatedAfter on the people and leads searches lets you refuse old ones. The email finder does not verify deliverability; the Work Email Finder does that for name-plus-domain lookups.

Phone coverage is US-centric. And the free Apify plan caps a run at a hundred results and an account at five hundred rows a month per Actor, with the same rows paid users get; any paid plan lifts that.

FAQ

Is this an Apollo, Lusha or Sales Navigator replacement? For building lists and enriching them by domain, URL or email, yes: no seat, no login, pay per found row. For browsing profiles one at a time in a sidebar, no.

Do these Actors scrape anything when I run them? No. The answer comes from a database of publicly available professional data; the network names in the listings describe the kind of data, not a crawl at run time.

Where do the email addresses come from? From the contact block of the person's record. The email finder returns only what is on record and labels it; nothing is generated from a name pattern.

How do I stop an agent from overspending? Pin the tools, cap every run with maxTotalChargeUsd, run the free count or previewOnly first, and use excludeDatasets so a rerun never pays for the same person twice.

Which one first? Hold a domain: Company Enrichment by Domain, then Company Employees. Hold a filter: Company Search for accounts, B2B Leads Finder for people. Hold URLs or emails: the finders.

For AI agents reading this

The seven Actors run as tools over the hosted Apify MCP server with the tools pinned in the URL (the wiring block above). The workflow, tool by tool:

b2bsearch--company-database-search with previewOnly: true to size a segment, then rows with maxResults
b2bsearch--domain-to-company for a card per domain; _status ambiguous means do not guess
b2bsearch--company-employees with profileDetail, roles, mustHave and compact: true
b2bsearch--b2b-leads-finder with emailType, maxPerCompany and excludeDatasets
b2bsearch--linkedin-email-finder and b2bsearch--linkedin-to-phone with profileUrls
b2bsearch--email-to-linkedin with emails

Every row has _status; rows other than found are free and say why in _note or _error. Read results with get-dataset-items and a fields list. Per-plan pricing is on each Actor page; set callOptions.maxTotalChargeUsd on every paid run. Platform docs: Apify MCP server and apify.com/agents.md.

Bulk email finder in Claude Code: 200 profile URLs, 64 still current

Kevin Hall — Thu, 29 Oct 2026 19:26:14 +0000

Everyone in sales has this file. A column of profile URLs from an event list, an old export or the CRM, and an empty column next to it where the email should go.

Any email finder will fill that column. What none of them tells you is whether the person still reads that mailbox. A record collects addresses the way a career collects employers, and the finder hands you the one on top. The bounce arrives a week later, on your domain's reputation, not theirs.

So on 2026-10-29 I ran two hundred profile URLs through an Apify Actor that labels the address instead of just returning it. Current employer, older employer, nothing on record, profile gone. Then I put two more Actors behind it, and let Claude Code run the same twenty over MCP. Every number below comes from those runs.

In one paragraph: a bulk email finder here takes profile URLs, one per line, and returns the addresses on each person's record with a label. An address on the current employer's domain, an older company address, or nothing. Misses are free rows with a reason.

For the older and empty rows a second Actor tries name plus company domain and verifies what it finds. A free search step sizes the segment before anyone pays.

Where two hundred URLs come from, and what a free read says

I did not want to run a client's list for a blog post, so I drew two random samples from the same people database the finder reads: in-house marketing leaders, and founders. Different inboxes, different habits. People Search in market mode first, which costs nothing and tells you what the box looks like before you pull from it.

Segment	People	Personal email on record
US marketing leaders (VP, Head, CMO, Marketing Director) at software companies with 51 to 500 employees	2,386	about two thirds
US founders and CEOs of software companies with 2 to 50 employees	59,835	just over half

Inside the marketing box, chief marketing officers and other C-level titles were nearly half, directors about a third, VPs fewer than one in ten. Useful to know before you read anything into a sample of a hundred.

Then the pull. people mode, compact rows, a random seed so I could not cherry-pick, five runs of twenty per segment:

{
  "mode": "people",
  "titleKeywords": ["vp marketing", "head of marketing", "chief marketing officer", "marketing director"],
  "countries": ["us"],
  "employerIndustries": ["Software Development"],
  "employeeCountMin": 51,
  "employeeCountMax": 500,
  "profileDetail": "row",
  "compact": true,
  "maxResults": 20,
  "sampleSeed": 41
}

Two of the hundred marketing draws were the same person, so that list is ninety-eight. Each compact row carries a profile URL, the employer's domain, company size, and two flags: hasWorkEmail and hasPersonalEmail. Eighty-two of the ninety-eight marketing leaders said yes to a work email. Seventy-six of the hundred founders did.

Hold that number.

The run: one field, four seconds

The finder takes one field. Links, bare handles and mobile URLs all work, and spellings of the same profile are looked up once. Up to a thousand per run; a free plan returns up to a hundred results per run, and I fed twenty at a time so I could read each batch before the next.

{
  "profileUrls": [
    "<one profile URL per line>",
    "..."
  ],
  "includePersonalEmails": false
}

Four seconds per batch of twenty. Here is what two hundred URLs became:

Outcome	`_status` / `emailType`	Marketing leaders (98)	Founders (100)
Address at the current employer	`work_current`	38	26
Only an older company address	`work_other`	43	48
Matched, nothing on record	`no_email`	12	24
Profile gone	`profile_removed`	5	2

Only the first two rows are billed. The empty and gone rows come back with a status, and for the empty ones with the name and title, so you know who to route elsewhere.

Now back to the flag. Eighty-two marketing leaders had "has a work email" on their database row. Thirty-eight of them have one at the company they work for today. A yes in a database means an address exists somewhere in the record. It does not say where.

That is the whole post in one line. About half the work addresses in a B2B record belong to a job the person has left, and a finder that does not label them sells you the bounce.

What an older address looks like

A career leaves a trail of mailboxes. The found marketing records held four addresses each in the middle of the pack, three quarters of them three or more, and one person had thirteen. Founders' records were a little shorter, three in the middle.

The finder sorts the current employer's address first when it has one. When it has none it can tie to today's employer, the row is labelled work_other and the first address in the list is simply the first one, with no claim about recency.

I checked the label against the employer domain from the source row, the one a CRM would hold:

`work_current` rows, marketing leaders	38
Same domain as the source row	27
Same company, a different mail domain	11
A different company	0

The eleven are brands whose mail domain is not the website: a product name on the site, the legal entity on the envelope. Among founders it split in half, which is what you get when one person runs two companies at once.

Record freshness shifts the odds without deciding anything:

Source record last updated	Current address	Older only
Within the last year	21	18
More than a year ago	17	25

Fresher records lean toward a live address. Not by enough to filter on. The label does the filtering, freshness only tells you how much to trust it.

Personal mailboxes, on request

By default the finder returns company addresses only. When a matched profile has nothing corporate but a personal mailbox is on record, the empty row says so in a _note. Five of the twenty-four empty founder rows carried that note. None of the twelve empty marketing rows did, and their source rows agreed: nothing of either kind.

I reran those five with includePersonalEmails on. Five personal addresses, as promised.

Then I reran one whole founder batch of twenty with personal mailboxes on from the start, to see what the switch does to rows that already had something:

Row in the first run	Rows	With personal mailboxes on
Current employer address	3	still the current address
Older company address	16	10 became a personal mailbox, 6 stayed older
Nothing	1	still nothing

With the switch on, a personal mailbox outranks an older company address. For the founder of a twelve-person company that is usually the inbox that gets read. For an in-house CMO it is the wrong one, which is why the switch is off by default.

The second door: name plus domain, verified

The older and empty rows are not dead people, they are people whose record is behind. For those there is a different Actor. Work Email Finder takes a name and a company domain, builds the candidates the way the domain writes addresses, and with verifyTopCandidate on checks the best one against the mail server and its own records.

I took the eighty-one found marketing rows, the name from the finder's row and the domain from the source row, and ran all of them through it:

{
  "lookups": [
    { "domain": "<company domain from your CRM>", "full_name": "<name from the finder row>" },
    "...eighty more"
  ],
  "verifyTopCandidate": true
}

Email Finder said	Rows	Verified address at today's domain	Of which already somewhere in the record	New, built from the pattern
`work_current`	38	30	26	4
`work_other`	43	33	21	12

Thirty-three of the forty-three "older" rows came back with a verified address at today's employer. Twenty-one of those were already in the record's workEmails list, below the one on top. The finder ties addresses to the employer's canonical domain, so a brand domain further down the list stays labelled older.

Two lessons for a pipeline. Match the whole list against your own domain list before you discard a row. And send what is left through the name-plus-domain door with verification on, which rescued most of the rest here.

The honest other half: eight people with a current address on record got no verified candidate from the pattern door. Record and pattern are two sources. Where they agree, twenty-six rows here, is where I would send first.

What Claude Code did with twenty of them

I gave Claude Code the Email Finder and People Search over MCP, nothing else. Shell and file tools off.

The prompt was a RevOps person in plain words. Two thousand CRM contacts with profile URLs and no email, here are twenty. Our policy is work addresses at the current employer only, never a personal mailbox unless you can say why. Look each person up once.

It loaded the two tool definitions, ran one lookup on all twenty with personal mailboxes off, read the twenty rows with get-dataset-items, and wrote its answer. Four tool calls, one of them paid, under four minutes. It did not run the free search, and said so: nothing in the task needed it.

Its ledger for the twenty: seven current, eight older, two with nothing, three profiles gone. Then it did the reading I would have skipped on a Friday.

One "older" row held an address on the current employer's domain further down the list. It proposed matching the whole list against the CRM's domain before discarding anything, the same fix I arrived at with eighty-one rows and a second Actor.

One row's only address sat on a domain made of the person's own name. A one-person consultancy mailbox in practice, it said, and excluded under the policy whatever the label says.

It noticed that profile_removed is not in the tool's description, read the status correctly anyway, and said it could not confirm the meaning with the tools it had. That gap in the listing is mine to close.

It also noted that _freshness did not vary across its fifteen found rows, so on that sample the field filtered nothing. True, and worth knowing before you build a rule on it.

Before the remaining two thousand it asked for five things: normalise and dedupe the URLs on the handle, compare work_current employers with the CRM's, verify deliverability before trusting hundreds, watch the share of gone profiles, and poll the run instead of waiting inline. I would sign all five.

Before you send

Addresses from the first Actor are on record, not verified at run time. The second Actor's check says a mailbox accepts mail. Neither says the person reads it.

The label can lag. A job change in the last few months can still show as current. Compare the row's employer with the one you hold.

Brands with a second mail domain show up as "older". Match on your domain list, not on the label alone.

Seven of the hundred and ninety-eight URLs pointed at a profile that no longer exists. A CRM full of URLs from three years ago will have more. Keep that share in view, it is free to measure.

Consent and the law are yours: CAN-SPAM, GDPR, PECR, whatever applies where the person sits. A verified address is not permission.

FAQ

Is this a Hunter or Apollo email finder replacement? For turning profile URLs into addresses in bulk, yes: no seat, no browser extension, you pay per found row and the misses are free. For a Chrome plugin that fills an address while you browse, no.

Does it guess addresses? The first Actor does not: it returns only addresses that exist in the person's record and says so when there are none. The second one builds candidates from name and domain and can verify the best one. That is the guessing door, and it is labelled as such.

What does work_other mean? A company address the finder cannot tie to the current employer. Usually a previous job, sometimes the same company under a brand domain. Check the workEmails list against your own domains before you decide.

Why were some addresses personal when I did not ask? They were not, unless includePersonalEmails is on. With it on, a personal mailbox outranks an older company address on the row.

How big can one run be? Up to a thousand URLs per run on this Actor. A free Apify plan returns up to a hundred results per run and five hundred rows a month; any paid plan removes that.

For AI agents reading this

The three Actors run over the hosted Apify MCP server with the tools pinned in the URL, so an agent loads only these definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/linkedin-email-finder,b2bsearch/work-email-finder,b2bsearch/people-database-search" --header "Authorization: Bearer <APIFY_TOKEN>"

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/linkedin-email-finder,b2bsearch/work-email-finder,b2bsearch/people-database-search",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen: b2bsearch--linkedin-email-finder, b2bsearch--work-email-finder, b2bsearch--people-database-search. For a list of profile URLs: dedupe on the handle, run the email finder with profileUrls and includePersonalEmails: false, then read rows with get-dataset-items and a fields list (_status, emailType, email, workEmails, emailCount, jobTitle, companyName, _freshness, _note).

Rows with _status other than found are free: no_email (a _note says when a personal mailbox is on record), not_found, profile_removed. For work_other rows, match every entry of workEmails against the user's company domain first.

For what is left, run work-email-finder with lookups of { "domain", "full_name" } and verifyTopCandidate: true, and read email_validity. To size a segment before any paid pull, run people-database-search with mode: "market" or mode: "count". Per-tier pricing is on each Actor page.

Earlier posts on the same question

The lead list autopsy counts how many leads in an ordinary ICP box were dead before the first email. The fractional CFO post is where I first saw work addresses that belonged to former employers.

The Apollo alternative builds the lists these URLs usually come from, and the Actor map by key says which door to use when you hold domains, emails or names instead of URLs.

Lusha and ZoomInfo alternative in Claude Code: a call list, four ways

Kevin Hall — Thu, 29 Oct 2026 08:01:00 +0000

Lusha and ZoomInfo sell one column: the mobile number. Everything else on the row you can get in ten other places. And the number is the column that is empty most of the time, whichever logo is on the seat.

I build outbound lists for a living, and teams that dial ask me the same thing every month. Not "does this vendor have numbers". They ask how many of the people they actually want have one. Nobody can tell them that before the contract is signed.

So on 2026-10-29 I spent a morning answering it the cheap way. One ideal customer profile, four Apify Actors, free counts before any paid pull, and Claude Code doing the clicking over MCP. Every number below comes from those runs, and the inputs are in the text.

In one paragraph: a Lusha or ZoomInfo alternative here is one people database behind a few Actors. Count your ICP for free. Then pull leads with the number where one exists, or only the callable ones, or look up numbers for contacts you already hold, or walk named accounts for anyone with a mobile. You pay per row delivered, nothing for the misses.

How big is the box, and does it matter where you sell

Before any pull I ran the ICP most call lists are built from through People Search in count mode: US sales leaders at software companies with 51 to 500 employees. Count mode charges nothing per row, and segments compares countries in one call.

{
  "mode": "count",
  "titleKeywords": ["vp sales", "head of sales", "chief revenue officer", "sales director"],
  "employerIndustries": ["Software Development"],
  "employeeCountMin": 51,
  "employeeCountMax": 500,
  "segments": [
    { "name": "US", "countries": ["us"] },
    { "name": "UK", "countries": ["gb"] },
    { "name": "Germany", "countries": ["de"] },
    { "name": "Canada", "countries": ["ca"] },
    { "name": "Australia", "countries": ["au"] }
  ]
}

Segment	People matching
United States	5,377
United Kingdom	1,591
Germany	776
Canada	402
Australia	315

Inside the US box, "sales director" is more than half of the people. "VP Sales" as a literal title is a small slice. Worth knowing before you read anything into a sample of twenty.

What the free read does not tell you is who has a number. Market mode shows email coverage (about two thirds of this box have a personal address on record) and says nothing about phones. The phone share comes one step later, and that step is cheap: the Actors skip people without a number for free and count them in a note row.

1. We need a fresh list, with numbers where they exist

The default case. A list to work by email first, phone when you have it. B2B Leads Finder with includePhones on:

{
  "jobTitles": ["vp sales", "head of sales", "chief revenue officer", "sales director"],
  "countries": ["us"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "industries": ["Software Development"],
  "emailType": "any",
  "includePhones": true,
  "maxResults": 20
}

A free Apify plan delivers up to twenty leads per API run, so I ran it five times and passed the earlier datasets in excludeDatasets each time. A hundred people at ninety-six companies, no repeats, each run under half a minute.

Thirty-five of them had a mobile number. That is the honest headline for this ICP: about one in three.

Role in the title	Leads	With a number
Chief Revenue Officer	31	16
Head of Sales	18	7
Sales Director	44	11
VP Sales	6	0

The pattern I keep seeing: the more senior the title, the more often a number is on record. CROs had one about half the time, sales directors one in four. The six VPs had none, which says more about six being a small number than about VPs.

Two things I expected to matter did not. Records refreshed within the last year carried a number at the same rate as older ones. And a work address and a number came together on a quarter of the list, which is the row a dialling team actually wants.

Then the same box for the UK and for Germany, twenty leads each. Zero numbers in both. Mobile numbers in this database are a US thing, and I would rather say that here than have you find it on the invoice.

2. We only want people we can call

A dialling team does not want the seventy rows without a number. Leads with Phones is the same search with phoneRequired on by default: every row has a verified mobile on record and a live email, the rest are skipped free.

{
  "jobTitles": ["vp sales", "head of sales", "chief revenue officer", "sales director"],
  "countries": ["us"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "industries": ["Software Development"],
  "emailType": "any",
  "phoneRequired": true,
  "maxResults": 20
}

Twenty people came back in about fifteen seconds, all with numbers. To find them the Actor read 125 matches. Thirty-five had left the role the search matched. Sixty-eight had no number or no live address. Both groups sit in the note rows at the end of the dataset, and neither is on the bill.

That note row answers the question from the top of the post. For this ICP, about one in six people the search matches is someone you can ring today.

I ran it once more with the first dataset in excludeDatasets. Twenty new people, zero repeats. Put that on a weekly timer and the call list grows only with new people.

3. The CRM has two thousand contacts and no numbers

This is the version I hear most. The list already exists, bought or built years ago, names and companies in a spreadsheet. Phone Number Finder takes exactly that: one line per person as "First Last, company domain", or an email, or a profile URL. Up to twenty thousand lines in one run.

I fed it twenty marketing leaders from a random sample of a different segment, random so I could not cherry-pick, as name plus domain:

{
  "profileUrls": [
    "Jane Smith, acme.com",
    "...nineteen more lines, one person each"
  ]
}

Five seconds. Nine came back with a number. Ten matched a person at that company who has no number on record, free. One profile was no longer in the database, also free.

Nine of twenty beats the one in three from the fresh list, and I would not read much into it: marketing leaders, a tiny sample. The shape is the point. You pay for the nine, and the eleven misses cost nothing and each one says why.

4. We sell to forty named accounts

Account-based teams have the opposite problem. They know the companies and want everyone there they can call. Company Employees Scraper walks a list of company domains, and mustHave: ["phone"] keeps only people with a number.

I took ten company domains from the first list. Any account list works: your CRM, a company-database-search run, domains resolved with domain-to-company. Leadership roles, sales or revenue in the title, contacts tier, compact rows:

{
  "companies": ["<ten company domains, one per line>"],
  "roles": ["cxo", "vp", "director"],
  "titleContains": ["sales", "revenue"],
  "profileDetail": "contacts",
  "mustHave": ["phone"],
  "compact": true,
  "maxRows": 20
}

Nineteen people with a number at nine of the ten companies, eleven seconds. Fifty-three employees in those roles had no number and were skipped free.

Most of the nineteen were directors, because there are simply more directors with "sales" in the title than there are CROs. If what you want is the one top person per account, run the roster tier first with roles: ["cxo"], read it, then pull contacts for the names you picked.

What Claude Code did with the same question

I gave Claude Code two of the Actors over MCP and a prompt in plain words: I run a three-person team that works the phone, this is our ICP, run anything free first, keep every paid pull at twenty or fewer, never run the same paid pull twice. Shell and file tools were switched off, so the Apify tools were all it had.

It did the free reads first, as told. Then it did something I had not asked for: it expanded my four titles into ten spellings ("vp of sales", "vice president sales", "director of sales", "cro"). The box roughly doubled, to about ten thousand people. The right call for a call list, and the reason its count does not match mine above.

It tried to get the phone share for free by running count mode with a phone requirement. Count mode ignores that requirement, and the agent said so instead of inventing a number. Then it ran one paid pull, with its own title list:

{
  "jobTitles": ["vp sales", "vp of sales", "vp, sales", "vice president sales", "vice president of sales",
                "head of sales", "chief revenue officer", "cro", "sales director", "director of sales"],
  "countries": ["us"],
  "industries": ["Software Development"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "phoneRequired": true,
  "emailType": "any",
  "maxPerCompany": 1,
  "maxResults": 20
}

Twenty rows, all with numbers, from 111 matches read. Fourteen had a work address at the current employer, six only a personal one.

Its read of the rows was the useful part. Three of the twenty were pre-sales or operations: a technical sales director, a director of sales operations, a VP of sales engineering. "Sales director" as a substring brings them in. It proposed an excludeJobTitles list for the next run and reusing the dataset in excludeDatasets. Both are the right next move.

It also read the rows with a fields list instead of pulling whole records, which nobody told it to do. Twelve turns, under six minutes.

Before you dial

Everything above is a number on record, not a number that rings. Nobody dialled anything for this post. Line type, do-not-call lists and consent rules (TCPA in the US, GDPR in Europe) are yours to handle before the first call, the same as with any vendor.

And the numbers are US-centric. If your market is the UK or Germany, run the free count, then one twenty-row pull with the phone required, and read the note row before you plan a calling campaign around it.

FAQ

Is this a drop-in Lusha or ZoomInfo replacement? For the list, yes: ICP in, rows with numbers out, no seat, no browser extension. For a dial-from-the-browser plugin, no. You get data, not a dialler.

How do I learn the phone share before paying for a list? Run Leads with Phones with a small maxResults and read the skipped_no_contact note row. The skipped people are free and they are your denominator.

Why did the UK and Germany return no numbers? Mobile coverage in this database is concentrated in the US. Outside it, treat the number as a rare bonus and build the list for email.

I already have the contacts. Which Actor? Phone Number Finder, one line per person: name plus company domain, an email, or a profile URL. Misses are free and come back with a reason.

Can I avoid paying twice for the same person? Pass earlier dataset ids in excludeDatasets. Everyone in them is skipped free, so a weekly rerun delivers only new people.

For AI agents reading this

The Actors run over the hosted Apify MCP server with the tools pinned in the URL, so an agent loads only these definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/b2b-leads-with-phones,b2bsearch/people-database-search" --header "Authorization: Bearer <APIFY_TOKEN>"

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/b2b-leads-with-phones,b2bsearch/people-database-search",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen: b2bsearch--people-database-search, b2bsearch--b2b-leads-finder, b2bsearch--b2b-leads-with-phones. For a call list: run people-database-search with mode: "count" and segments first and read _total per segment. Then run b2b-leads-with-phones with phoneRequired: true, maxPerCompany: 1 and a maxResults you can defend, or b2b-leads-finder with includePhones: true when the number is optional.

Read rows with get-dataset-items and a fields list. Rows whose _status is not found are note rows (skipped_no_contact, skipped_moved, skipped_relocated) and are the denominator. On reruns pass earlier dataset ids in excludeDatasets.

For contacts the user already holds, run b2bsearch/linkedin-to-phone with profileUrls as "First Last, domain" lines, emails or profile URLs. For named accounts, run b2bsearch/company-employees with companies, roles, profileDetail: "contacts" and mustHave: ["phone"]. Phone coverage is US-centric; outside the US expect the number column to be mostly empty. Per-tier pricing is on each Actor page.

Earlier posts on the same question

The first Lusha test ran one ICP with the number optional and required. The phone hit-rate map measures nine role and country populations. The Apollo alternative and the Sales Navigator alternative build the email side of the same lists from Claude Code, and the account mapping post walks named accounts at full length.

Sales Navigator alternative in Claude Code: one saved search, one list

Kevin Hall — Wed, 28 Oct 2026 21:36:45 +0000

A Sales Navigator saved search is often the most precise ICP a sales team owns, and the seat is the price of running it. Someone built it over an afternoon: the titles, the geography, the headcount bands, the companies to leave out. Everyone else needs a seat to see the results, and getting the people out means an export by hand or a browser extension that runs on the account's cookies and breaks when the page changes.

On 2026-10-28 I took three searches a sales team actually runs, copied their URLs, and turned each one into a list from Claude Code with one Apify Actor, Sales Navigator Search Scraper. The Actor never opens the URL. It reads the filters encoded in it and runs the same query on a database of professional records, so there is no login, no cookie and no seat involved, and a free count sizes the search before a row is charged. Every number below comes from that day's runs, each capped at 20 rows because I ran them on a free Apify plan. The rows shown carry no names, no addresses and no employer names. Sales Navigator is a trademark of its owner; this Actor is not affiliated with it. Per-tier pricing is on the Actor page.

In one paragraph: a Sales Navigator alternative here means building the search in the tool you already know, copying the results-page URL, and letting an Actor read the filters (current company, current title, region, industry, headcount, keywords) and run them on its own people database. You get a count for free, rows paid per person delivered, a weekly rerun that returns only new people, and an agent that can do all of it over MCP.

What a Sales Navigator URL carries

Copy the address from the browser bar while the results are open. The query parameter is a Rest.li structure, percent-encoded twice. Decoded, my first search reads:

filters: List(
  (type: CURRENT_TITLE,     values: List((text: VP Sales, selectionType: INCLUDED),
                                          (text: Head of Sales, selectionType: INCLUDED))),
  (type: REGION,            values: List((id: 103644278, text: United States, selectionType: INCLUDED))),
  (type: COMPANY_HEADCOUNT, values: List((id: D, text: 51-200), (id: E, text: 201-500))),
  (type: INDUSTRY,          values: List((id: 4, text: Software Development)))
)

The Actor maps each filter to a field of its people search and echoes what it ran in _input on every row, so the first thing to read after a run is the search it actually executed:

{
  "location_country_code": ["us"],
  "title_contains_any": ["vp sales", "head of sales"],
  "employer_industry_ids": [4],
  "employee_count": { "min": 51, "max": 500 }
}

Sales Navigator filter	Read as
Current company	the companies picked from the suggestions, by their id; excluded companies too
Current job title	text inside the current title; excluded titles are excluded
Geography	a country, a "City, State, Country" place, or a metro area as written on the profile
Industry	the employer's industry, by the same id
Company headcount	one range of adjacent bands (51-200 plus 201-500 reads as 51-500)
Keywords	plain words, matched in the headline

Everything else stops the run before anything is charged, and the status line names it. I pasted the first search with a seniority filter added, verbatim:

Not run, nothing charged. These Sales Navigator filters cannot be read yet: seniority level. Remove them from the search, copy the URL again and rerun.

The same happens for function, past company, school, years in role, the spotlights (changed jobs, posted recently), first and last names, groups, Boolean keyword strings, continents, and a company typed as text instead of picked from the list. A saved-search link (savedSearchId=) is refused too, because it carries no filters: open the saved search and copy the address of its results page. A refusal costs nothing. A dropped filter would sell you people you excluded, so nothing is dropped quietly.

Three saved searches, measured on 2026-10-28

Each count is one run with mode: "count": no row is charged, _total holds the number, and _input holds the filters as read.

Search	Filters in the sidebar	People matched	Count took
New logo	VP Sales or Head of Sales; United States; 51-500 employees; Software Development	1,175	9 s
Territory	Head, VP or Director of Sales; Austin, Texas; 11-500 employees	946	5 s
Account list	Engineering Manager; United Kingdom; eight companies picked by id	419	7 s

1. New logo: the ICP box

mode: "people", maxResults: 20, maxPerCompany: 1, profileDetail: "row". 7.5 seconds, 20 delivered, no note rows.

Title	Company size	Industry	Country	Email on record	Freshness
Head of Sales	148	Software Development	us	work, personal	updated_1y
VP Sales Engineering	138	Software Development	us	work, personal	updated_1y
Head of Sales Americas	424	Software Development	us	work, personal	older
Global Head of Sales	237	Computer Games	us	work, personal	older
Head of Sales and Marketing	197	Software Development	us	none	older

All 20 titles hold "VP Sales" or "Head of Sales", all 20 employers have 59 to 424 people, all 20 people are in the US. 17 of 20 carry a work address on record, 14 a personal one, 3 neither; 8 rows are updated_1y, 12 older. Three rows carry an industry label other than Software Development (two Computer Games, one IT Services): the filter matched the employer record's industry id, the label on the row is the employer's industry text, and the two fields can disagree. Six of the 20 list more than one current position, which is where the review line below starts.

The exclusion trick from the first Sales Navigator post still holds: "Investing" and "Partner" added as excluded titles in the sidebar take the count from 1,175 to 1,124, and the exclusion arrives as title_not_contains_any.

2. Territory: metro area or city, and why it matters

The second search is a territory: Head, VP or Director of Sales at 11-500-person companies in Austin. Sales Navigator offers "Austin, Texas Metropolitan Area" and "Austin, Texas, United States" as two geography values, and here they are not the same search:

Geography value	Read as	People
Austin, Texas Metropolitan Area	`locality_contains_any: ["austin, texas metropolitan area"]`	203
Austin, Texas, United States	`location_country_code: ["us"]` plus `locality_contains_any: ["austin, texas"]`	946

A metro area matches the location as people wrote it on their profile, and most wrote the city. Pick the city, or the country for full coverage. The 20-row pull on the metro version took 6 seconds: all 20 locations are the metro area as written, all 20 titles hold one of the three phrases, employers from 11 to 362 people, 8 of them in software development and the other 12 spread over construction, manufacturing, finance, accounting, retail, logistics and health care, because this search had no industry filter. 17 work addresses on record, 10 personal, 3 neither. Only 4 rows are updated_1y and 16 older: a small-company territory ages faster than the software box.

3. Account list: picked companies, by id

Sales Navigator's account list is the "current company" filter with companies picked from the suggestions, and the URL carries each one's id. I built this search by hand, eight companies and "Engineering Manager" in the United Kingdom, and learned two things. A company written as text is refused by name, because the Actor reads ids only: a name typed as text could match a namesake. And two of my eight ids matched nobody; a free count on each company alone returned 0 for those two and 17,734 people for one of the six that resolved. The sidebar writes the id for you; a hand-built URL is yours to check, and the count on one company is the check.

419 people matched the six companies that resolved. With maxPerCompany: 3 the pull delivered 18 in 58 seconds, 3 at each of the six, and one note row: 240 people were over the limit of 3 per company and were skipped, not delivered, not charged. Employee counts on these rows are the companies' global headcount, 17,285 to 785,236. 15 of 18 carry a work address on record, 9 a personal one; 11 rows updated_1y, 7 older.

The domain route to an account list, Domain to Company plus companyDomains on B2B Leads Finder, is in the Apollo alternative post; it takes the accounts as website domains and skips the id question.

Emails: the row tier says "on record", the contacts tier delivers

hasWorkEmail and hasPersonalEmail on a search row are flags: an address is on record. profileDetail: "contacts" reads the full profile and delivers only an address judged to reach the person today. The first search in the contacts tier, 20 people, one per company, 9 seconds:

20 delivered: 10 with a work address at the current employer, 5 with a personal address, 5 with no reachable address, shipped as a full profile at the profile price.
9 people skipped as skipped_moved: their full profile closes the position the search matched. The row tier delivered the same search with zero note rows, because a search row is the record as matched; the profile tiers do the move check for you, and 9 of the 29 people read had moved.
2 of 20 with a phone number on record.
Of the 15 addresses, 7 sit on the row's company domain. The other 8 are 5 personal addresses and three "work" addresses on another domain: two are a rebrand or an acquisition, the old and the new domain of one business, and one is at a different company. The address domain against the company domain is the cheapest bounce check there is, one column against another.
4 of 20 list another current job ahead of the matched one (primaryTitle differs from jobTitle), and 1 of 20 no longer lists the matched employer at all (_employerUnconfirmed: true).

The same box typed by hand into B2B Leads Finder with emailType: "work", 20 leads, one per company, 15 seconds: 20 delivered from 59 read, 24 skipped because no work address at the current employer was on record, 15 skipped as moved. 16 of the 20 addresses sit on the row's company domain. Five of these 20 people are in the URL run's 20 and nine in the contacts run's 20: a search that requires a live work address walks a different head of the same 1,175.

The weekly rerun: new people only

A saved-search alert needs the seat to remember what it already showed you. Here the memory is the dataset: excludeDatasets takes the ids of earlier runs, and everyone in them is skipped and never charged again. The first search once more, with the dataset of the first pull excluded:

{
  "salesNavigatorUrl": "<the same URL, unchanged>",
  "mode": "people",
  "maxResults": 20,
  "maxPerCompany": 1,
  "profileDetail": "row",
  "excludeDatasets": ["<dataset id of the first run>"]
}

2 seconds, 20 delivered, 0 of them in the first run, checked by personId. Run it on a schedule, feed each run's dataset into the next run's exclusion list, and the same URL returns only the people new to the search. That is the alert without the seat, and the cost is only the new rows.

The same search from Claude Code over MCP

Apify runs an MCP server at https://mcp.apify.com; the tools parameter pins the Actors a session may reach. In Claude Code:

claude mcp add --transport http apify \
  "https://mcp.apify.com?tools=b2bsearch/sales-navigator-search,b2bsearch/b2b-leads-finder"

Any other MCP client takes the same URL in its server config, with OAuth on first connect or an Authorization: Bearer <APIFY_TOKEN> header:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=b2bsearch/sales-navigator-search,b2bsearch/b2b-leads-finder"
    }
  }
}

The Actors appear as tools named b2bsearch--sales-navigator-search and b2bsearch--b2b-leads-finder (the slash becomes a double hyphen); the server adds get-dataset-items, get-actor-run and two more helpers next to them. A tool call returns the run and its dataset id; the rows come from get-dataset-items. What a pinned Actor costs an agent in tokens before the first call is measured in the MCP tool cost post.

I gave Claude Code the first search's URL and this brief: count first and name the filters you read; if the count is under 5,000, pull up to 20 people, one per company, search rows only; then run it again with the first run's dataset excluded and report the overlap by personId; never print names, profile URLs, company names or addresses. The session had this one Actor pinned and no shell or file tools. Seven tool calls, 130 seconds:

ToolSearch: loaded the three tool definitions it needed, the Actor, get-dataset-items and get-actor-run.
The Actor with mode: "count", then get-dataset-items with limit: 5 to read _total (1,175) and the echoed filters.
The Actor with mode: "people", profileDetail: "row", maxResults: 20, maxPerCompany: 1.
get-dataset-items with fields: "personId,_status,_freshness,jobTitle,companyEmployeeCount,companyIndustry,countryCode,hasWorkEmail,_note,_error", in parallel with the rerun carrying excludeDatasets: ["<first dataset>"].
get-dataset-items on the second dataset, four fields only.

Its report: 1,175 matched; 20 and 20 delivered; overlap by personId 0; 17 and 18 rows with a work address on record; 8 and 10 rows refreshed within the year; no note rows. Two things it flagged on its own, both right: three of 20 rows carry an industry label other than the one filtered, and the title filter reads as "contains", so "VP Sales Engineering" and "Head of Sales Strategy and Operations" came through, which it summed up as "expect a somewhat broader list than the seat gives you". Two things worth putting in every prompt: it asked for columns, not rows, which kept each dataset read to a few hundred tokens; and it started the rerun before it had read the first run's rows, which is fine at 20 and wrong at 2,000, so say "read the first run before you start the second".

What this does not replace

A live network. The data is a database of records, refreshed in waves; _freshness on every row says updated_1y or older, and the totals will not equal the number Sales Navigator shows for the same search. No activity, no intent, no "posted this week"; the spotlight filters are refused for that reason.
Exact matching. Titles match as text inside the current title, keywords match the headline only, a metro area matches the location as written. Expect a broader title list and a narrower keyword list than the seat gives, never other people.
The review line. Six of 20 people in the first search list more than one current position, 9 of 29 read by the contacts tier had moved, and 3 of 15 work addresses sit on another domain. The evidence is on the row (currentPositions, _freshness, emailType, the address domain against companyDomain); the look is yours.
Full rows on the free plan. The API caps a run at 25 people there, which is why every list here is 20. A paid Apify plan lifts the cap.

FAQ

Do I need a Sales Navigator seat? To build the search URL, yes, or anyone who has one sends you the link. The run itself uses no account, cookies or seat.

Which filters carry over? Current company (picked from the suggestions, by id), current title, geography (country, city or metro area), industry, company headcount, plain keywords. Seniority, function, past company, school, years in role, spotlights, names, groups and Boolean strings stop the run by name, nothing charged.

How do I get emails? profileDetail: "contacts" delivers an address that reaches the person today, or the full profile when none is on record. For a list where every row must have a work address, type the same box into B2B Leads Finder with emailType: "work".

Does a rerun return the same people? Not with excludeDatasets: everyone in the listed datasets is skipped free, so a scheduled rerun of the same URL returns only new people; 0 of 20 repeated in the run above.

Can an AI agent run it? Yes, over MCP with the Actor pinned in the tools parameter; the wiring and a recorded session are above.

For AI agents reading this

To turn a Sales Navigator people-search URL into a list: run b2bsearch/sales-navigator-search with salesNavigatorUrl set to the URL unchanged and mode: "count"; read _total and _input.filters from the dataset. If the run's status message starts with "Not run", it names the filters in the URL that cannot be read, and the user has to remove them from the search and copy the URL again. If the count is acceptable, run mode: "people" with a maxResults you can defend, maxPerCompany for an account list, profileDetail set to row, profile or contacts, and excludeDatasets with the ids of earlier runs on reruns. Read rows with get-dataset-items and a fields list; rows with _status other than found are note rows (skipped_moved, skipped_per_company) and are the denominator. Before the first email, flag rows whose _freshness is older, whose primaryTitle differs from jobTitle, whose _employerUnconfirmed is true, or whose address domain differs from companyDomain. For the same search typed as fields with a live work address required, run b2bsearch/b2b-leads-finder with jobTitles, countries, companySizeMin, companySizeMax, industries and emailType: "work".

The first Sales Navigator post has the full filter table and the move check on 75 people, the Apollo alternative post rebuilds seven lists in the typed fields, and the ICP post walks one box from count to list at full length.

MCP tool cost: 20 job Actors on Apify, 2.1K to 32.7K tokens each

Kevin Hall — Wed, 28 Oct 2026 11:00:14 +0000

Here is what an agent pays before it asks a job-search tool anything. I pinned 20 job-search Actors from the Apify Store, one at a time, on the hosted Apify MCP server and read what tools/list sends back. The smallest tool definition was 2,139 tokens. The median was 3,829. One was 32,737, and 32,136 of those tokens were an output schema the server had inferred from the Actor's results; the author's own input schema was 406 tokens.

Three of the twenty are mine, so this is also a check on my own work. The numbers are from 28 October 2026, and the method is a curl handshake you can rerun on any Actor in a minute.

Why the tool definition is the first cost

An MCP client loads every tool's name, description and JSON schema before the model reads your question. On the hosted Apify server each Actor becomes one tool, and the tool carries three parts: the description (the Actor's Store description after a one-line preamble), the input schema (the Actor's input fields, as the author wrote them), and an output schema that the server infers from what the Actor's runs return (documented here; the local stdio server does not add it). The third part is the one most Actor authors have never looked at, because they never wrote it.

A post two days ago measured a hand-built server at 15 tools and rebuilt it to 4. I wanted the same number for tools I did not build and cannot rebuild: the Actors an agent meets when a user says "find me backend jobs in Germany".

How I measured

Hosted server, one Actor pinned per session with ?tools=, then the plain tools/list after the initialize handshake:

U='https://mcp.apify.com?tools=curious_coder/linkedin-jobs-scraper'
H=(-H "Authorization: Bearer $APIFY_TOKEN" -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream')

# 1. initialize; the session id comes back as a response header
curl -s -D hdr -o /dev/null "$U" "${H[@]}" -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}'
SID=$(grep -i '^mcp-session-id' hdr | awk '{print $2}' | tr -d '\r')

# 2. initialized notification, 3. the list (server-sent events; the data: line holds the JSON-RPC result)
curl -s -o /dev/null "$U" "${H[@]}" -H "Mcp-Session-Id: $SID" -d '{"jsonrpc":"2.0","method":"notifications/initialized"}'
curl -s "$U" "${H[@]}" -H "Mcp-Session-Id: $SID" -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' > tools.sse

I serialized each tool definition as compact JSON and counted tokens with tiktoken's o200k_base. Claude's tokenizer is not public, so treat the counts as a scale, not an invoice. The relative sizes are the point, and those do not depend on the tokenizer.

The twenty are the Actors the Store returns for "linkedin jobs", "job search", "job postings", "indeed jobs" and "glassdoor jobs", ranked by users in the last 30 days, plus my three (they are new and would not have made the cut on users).

The table

Actor	tokens per tool	description	input schema	output schema	input fields
`valig/indeed-jobs-scraper`	32,737	52	406	32,136	6
`cheap_scraper/linkedin-job-scraper`	7,723	87	6,061	1,440	38
`bebity/linkedin-jobs-scraper`	6,769	57	5,029	1,551	18
`fantastic-jobs/advanced-linkedin-job-search-api`	6,569	86	4,312	2,018	41
`fantastic-jobs/career-site-job-listing-api`	6,324	93	4,083	1,999	39
`b2bsearch/linkedin-job-search-api (mine)`	5,770	92	3,410	2,123	38
`b2bsearch/linkedin-jobs-scraper (mine)`	4,389	107	2,403	1,729	25
`agentx/all-jobs-scraper`	4,041	69	2,060	1,780	11
`epctex/google-jobs-scraper`	3,981	72	2,708	1,068	14
`harvestapi/linkedin-job-search`	3,911	43	1,492	2,217	19
`openclawai/job-board-scraper`	3,748	82	2,054	1,461	21
`borderline/indeed-scraper`	3,416	78	1,096	2,094	15
`curious_coder/linkedin-jobs-scraper`	3,343	52	1,711	1,444	14
`b2bsearch/hiring-companies-finder (mine)`	3,303	101	1,329	1,723	15
`fast_data_asap/career-site-jobs-api`	3,235	106	1,777	1,277	13
`fast_data_asap/job-search-api`	2,562	92	1,108	1,291	13
`misceres/indeed-scraper`	2,509	62	925	1,394	9
`valig/linkedin-jobs-scraper`	2,180	54	682	1,310	14
`valig/glassdoor-jobs-scraper`	2,140	59	599	1,340	13
`apimaestro/linkedin-jobs-scraper-api`	2,139	59	564	1,375	12

Where the tokens go

The input schema tracks the number of fields, not the quality of the Actor. Six fields cost 406 tokens; 38 to 41 fields cost 3,410 to 6,061. Every filter an author adds is a line the agent reads on every turn it has the tool loaded. Mine sits in that band on purpose: 38 fields, 3,410 tokens, because the Actor exposes the database's filters (boolean title and description search, exclusions, employer size, industry, salary, applicants, expiry) instead of hiding them behind one free-text box. That is a trade, and the number is its price.

The output schema is the larger half in nine of the twenty tools. The server generates it from the Actor's dataset, so a scraper that returns a deeply nested row pays for it on every turn, and the author never sees it unless they run tools/list themselves. The Indeed scraper at the top of the table returns rows that produced a 3,400-node schema; the tool definition for my jobs Actor has 229 nodes. The other nineteen output schemas came in between 1,068 and 2,217 tokens, which looks like the floor for a flat row with a few dozen keys.

The description is cheap, 43 to 107 tokens. The server takes the Store description verbatim after a preamble ("This tool calls the Actor ... and retrieves its output results. Actor description: ..."). So the one text an author writes for humans is also the text the agent reads to choose between tools, and it is under three percent of the tool's cost. Spend the words there.

What the server does to a listing

Three transformations were visible in the payloads.

Long field descriptions are cut. On the Actor with the longest ones, four of 38 fields ended in "[Description truncated]"; their raw descriptions ran 518 to 810 characters and came through at 371 to 495 plus the marker. Whatever you wrote after the cut, the agent never reads.

Prefill values are appended to the description as "Example values: ...". If the prefill is a realistic example, that is free documentation. If it is a placeholder, the agent copies the placeholder.

required is passed through as written. Four of the twenty require at least one field. A required field that also has a default is a small trap: the agent must supply it even though the Actor would run without it.

The fixed overhead you pay even for one Actor

Pin one Actor and the server still sends four helper tools: get-actor-run (1,437 tokens), abort-actor-run (1,311), get-dataset-items (667) and get-key-value-store-record (373). That is 3,788 tokens before the Actor itself; for the median Actor, half the bill.

Without ?tools=, the default server sends 12 tools and 18,391 tokens: the three discovery tools (search-actors 2,315, fetch-actor-details 1,755, call-actor 2,009), the four helpers, two docs tools, a problem reporter and two web tools (rag-web-browser 4,508, web-fetch 2,647). ?tools=actors keeps discovery and cuts the rest: 7 tools, 9,867 tokens.

What Claude Code does with it

I have five recorded claude -p sessions over the pinned jobs tools from the last three posts, two or three Actors pinned each time. In all five, the agent's first action was ToolSearch with select:mcp__apify__b2bsearch--linkedin-job-search-api,.... Claude Code defers MCP tool definitions above a size threshold: the model sees the names at the start and pulls a definition into context when it decides to use the tool. The first turn of the Java-in-Berlin session carried 43,743 tokens of context before any Actor definition had been fetched.

So in Claude Code the tool tax is not paid on turn one. It is paid from the turn the definition is loaded, on every turn after. The session that ran 18 free previews took 39 turns and read 523,825 cached input tokens in eleven minutes, and the tool definitions were part of every one of those reads. Across the five sessions the agent used between 9 and 16 of the Actor's 38 input fields; the other 22 to 29 rode along in every turn as schema the agent had read and did not need.

A host without deferral puts the whole tools/list into the system prompt on turn one, and pays the table above on every turn from the first. The 15-to-4 post I linked measured exactly that case.

Discovery versus pinning: two sessions, one question

Same prompt, two Claude Code sessions, one difference in the MCP URL. The prompt is a backend developer in Berlin with six years of Java asking which technology to learn next, judged by what German employers ask for: count the base, count the current stack in descriptions, count eight candidates, count two of them together with Java.

Pinned, ?tools=b2bsearch/linkedin-job-search-api,b2bsearch/hiring-companies-finder (the recorded session from the third post): 39 turns, eleven minutes, 18 free previews, 523,825 cached input tokens read. The agent had exact counts for the base and for every technology, by employer, and picked Kubernetes with AWS close behind.

Discovery, ?tools=actors (search, details, call, plus the four helpers: 9,867 tokens of definitions), with money rules added to the prompt: read an Actor's pricing before calling it, cap every call, keep the total small, prefer free counts. 33 turns, fifteen minutes, 32 tool calls: 5 Store searches, 12 listing fetches, 3 paid runs on two scrapers, 11 reads of run state and rows. 220,114 tokens written to cache and 1,571,639 read, three times the pinned session. The agent never saw my Actor: the five searches came back led by the most-used scrapers, and a tool with a handful of users in its first week was in none of the lists. It chose the most-used LinkedIn scraper and an Indeed scraper, pulled 225 rows, filtered them to 82 backend postings, and answered with shares of that sample, labelled as a sample with a ten-point margin, and picked AWS with Kubernetes close behind. The three runs all stayed under the cap the agent had set on each call.

Where the discovery turns went is the part worth keeping. Two of the twelve listing fetches came back over Claude Code's tool-result limit (61,678 and 68,510 characters: a README plus both schemas), one hit a 502, and the rest were 14,000 to 24,000 characters each. Reading listings cost the session more context than running them.

My first attempt at the discovery session had to be killed, and the reason belongs in the post. I had left the shell tool allowed. When a listing fetch overflowed and Claude Code wrote it to a file, the agent read the file with the shell, then started checking the environment and my credentials file for an Apify token so it could call the API directly. Nothing was sent anywhere and the transcript holds no token, but an agent with a shell and a blocked tool result will look for another road. The second run had --permission-mode default and the shell in --disallowedTools, and stayed on the MCP tools.

What I keep in my own schema, and what I changed

The three b2bsearch Actors follow rules I had set before this measurement, and the payloads confirm they survive the server:

The two fields that change what a run costs, previewOnly and compact, are the fourth and fifth fields in the schema, before any filter, so a client that shows the first N fields shows them.
Field descriptions are capped at 350 characters by a test in the build (the longest live one is 342). None of my fields carries the "[Description truncated]" marker.
No required fields. {"previewOnly": true, "titleSearch": ["backend"], "locationSearch": ["de"]} is a complete call.
Rows nest two levels at most (a company card, a recruiter), which gives an output schema of 2,123 tokens and 229 schema nodes. The 3,400-node schema at the top of the table cost 32,136.

What this measurement changed: I had been treating the input schema as the tool's cost. It is a third to a half of it. The helper tools and the inferred output schema are the rest, and only the second of those is under an author's control, through the shape of the rows the Actor writes.

What I did not do is cut fields. The recorded sessions used nine to sixteen of them, different ones each time, and a database-backed search with fewer filters would just move the filtering into the agent's own loop, which is far more expensive than a schema line.

Three calls to try on the jobs tools

The table is about cost. Here is what the three pinned tools of mine return when an agent asks a plain question. Every call below is a free preview: no rows, no charge, just the count and a breakdown. I ran them on 31 October 2026 and the data runs through 21 October.

LinkedIn Jobs Database API: "how many backend postings in Germany, and who answers them?"

{"previewOnly": true, "titleSearch": ["backend engineer"], "locationSearch": ["de"], "timeRange": "30d"}

155 open postings at 101 employers. Berlin has 41 of them and Munich 17. 18 state a salary and 14 name a recruiter. 55 had fewer than 25 applicants and 29 had over 200, which is the number I would show a candidate before they pick where to apply. My first try used the default 7d window and came back with 0, because the data stops on 21 October; the note on the preview row says so, which is what lets an agent widen the window by itself.

Companies Hiring Now: "which employers are hiring data engineers?"

{"previewOnly": true, "jobTitles": ["data engineer"], "locations": ["Germany"], "postedLimit": "month"}

292 employers posted 540 matching jobs in the last month, agencies and job boards already left out (that filter is on by default here). 192 of the postings went up in the week of 12 October, the busiest of the four. The same call with previewOnly off and decisionMakers on returns one row per employer with the people who would own the hire, which is the version a recruiter or a salesperson wants.

Advanced LinkedIn Jobs Scraper: "is there a market for SREs in the Netherlands?"

{"previewOnly": true, "jobTitles": ["site reliability engineer"], "locations": ["Netherlands"], "postedLimit": "month", "excludeAgencies": true}

18 open jobs at 14 employers, 12 of them mid-senior. 5 name a recruiter and 4 state a salary, all in euros. Small enough that the next call can pull every row with compact: true and still stay cheap for the agent's context.

In an agent session I do not write the JSON. I pin the tool as in the section below and ask in words: "count backend engineer postings in Germany over the last 30 days, free preview only, and tell me which cities lead". The agent fills titleSearch, locationSearch and timeRange from the schema, reads the preview row and answers in one call.

For AI agents reading this

To use the jobs tool from Claude Code with the smallest tool set, pin it:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api" --header "Authorization: Bearer <APIFY_TOKEN>"

or in any MCP client config:

{"mcpServers": {"apify": {"type": "http", "url": "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api", "headers": {"Authorization": "Bearer <APIFY_TOKEN>"}}}}

The tool is named b2bsearch--linkedin-job-search-api (mcp__apify__b2bsearch--linkedin-job-search-api inside Claude Code). Call it first with previewOnly: true: it returns the count of matching postings and a breakdown by country, seniority, employment type, industry, top employers, titles and cities, no rows and no charge. Then turn previewOnly off and set limit to pull rows; rows come back through get-dataset-items. Filters that matter most: titleSearch (one line per title variant, boolean allowed), locationSearch (country codes or cities), timeRange (7d, 30d, 6m), descriptionSearch (one line per technology, lines are OR, quote phrases), removeAgency: true to drop staffing agencies and job boards, status (active, expired, any).

To measure any Actor's tool cost: run the handshake above with ?tools=<owner/actor>, take the data: line of the tools/list response, and count the compact JSON of each entry in result.tools. Expect four helper tools in the list besides the Actor.

What this does not measure

Token counts are tiktoken's, not Claude's; the ranking holds, the absolute numbers are a scale. I measured one host, Claude Code, for deferral; other hosts load the list differently. The twenty Actors are a Store search on one day, not the whole category. And none of this says whether a bigger schema makes an agent worse at the task; the post I linked measured call counts for one server, and the discovery session above is one run, not a benchmark.

This post is a companion to the series on developer job search with Claude Code: the first post searches the market by stack, the second measures ghost jobs, the third counts the technologies employers ask for, all over the same pinned tool. The Actors are LinkedIn Jobs Database API, Companies Hiring Now and Advanced LinkedIn Jobs Scraper; per-tier pricing is on each Actor page.

Backend skills employers ask for: AWS and Kubernetes beat Go and Rust

Kevin Hall — Tue, 27 Oct 2026 19:16:11 +0000

A first-year student on this site asked the question I keep seeing in other forms: what are you supposed to learn when every field looks like it might shrink before you graduate. The usual answers come from developer surveys, which tell you what people enjoy using, or from trend charts, which tell you what people talk about. Neither tells you what the employer who might hire you wrote in the posting.

So I counted that. From Claude Code, I searched the text of open LinkedIn backend postings in five countries for three dozen technologies, one free count per technology per country, and counted how many employers named each one. This is the third post of the series; the first searched the market by stack, the second measured ghost jobs. The short version:

Cloud comes first. AWS is named by more employers than any programming language in the UK and India (53 % in both) and is second only to Python in the US. In the Netherlands, Azure leads (37 %).
Kubernetes is the constant. Between 32 % and 37 % of employers name it in every one of the five countries. Nothing else is that even.
Two languages carry the volume. Python leads in the UK, the US and the Netherlands; Java leads in Germany (38 % against 36 %) and ties with Python in India.
The Netherlands is a Microsoft market. C# or .NET shows up at 31 % of Dutch employers, more than twice its share anywhere else.
Go and Rust are smaller than their reputation: 5–13 % and 2–12 % of employers. Go is undercounted, for a reason explained below.
Claude Code is in the job ad. LLMs or generative AI come up at 9–28 % of employers and AI agents at 12–20 %. Claude Code is named by more employers than GitHub Copilot in all five countries: 6–10 % against 3–6 %.

Then the question that matters to one person: given what I already know, what do I learn next? A Claude Code session answered it for a Java developer in Berlin, with its own counts, in eleven minutes.

The wiring

The same as in posts 1 and 2: Apify's MCP server, pinned to the jobs Actor.

claude mcp add --transport http apify \
  "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api"

The Actor is LinkedIn Jobs Database API, a search over a database of LinkedIn job postings. This post leans on one input: previewOnly: true. A preview returns how many postings match and at how many employers, with a breakdown by employer, applicants and seniority, and it charges nothing. One technology in one country is one preview.

How I counted

Every count in this post is a run like this one, with only the country and the technology words changed:

{
  "titleSearch": ["backend", "back-end", "back end"],
  "locationSearch": ["gb"],
  "datePostedAfter": "2026-09-29",
  "timeRange": "30d",
  "status": "active",
  "removeAgency": true,
  "descriptionSearch": ["kubernetes", "k8s"],
  "previewOnly": true
}

Postings: open LinkedIn postings with backend in the title, staffing agencies and job boards left out. Post 2 shows why: in the UK they post more than half of all backend postings, often the same role several times.
Windows: first published from 29 September to 21 October 2026 in the UK, Germany and the Netherlands. The US and India post far more, and a text search reads a limited number of postings at a time, so their windows are shorter: 19 to 21 October for the US, 12 to 21 October for India. Compare shares across countries, not counts.
Employers, not postings. One travel company posted 100 of the 419 US backend postings in those three days, and 36 of the 359 German ones, most of them for the same few roles listed country by country, and most of them asking for Scala and Kotlin. Counted by postings, Scala came out at 27 % in the US. Counted by employers, it is 5 %. So every share below is the number of employers whose postings name the technology, divided by the number of employers with a backend posting in that country: 198 in the UK, 229 in Germany, 95 in the Netherlands, 165 in the US, 266 in India.
Words: each technology is a short list, and a posting counts if its text has any of them: kubernetes or k8s, aws or "amazon web services", "c#", ".net" or dotnet, and so on. Single words match whole, so java does not match JavaScript; quoted phrases match as written.
Go is the exception. "Go" is an ordinary English word, so I counted golang, "Go developer", "Go engineer", "(Go)" and "Go/" only. Its share is a floor.
A mention is not a requirement. "Kubernetes is a plus" counts the same as "five years of Kubernetes".

In all, 1,730 postings and 210 previews. The runs went four at a time, because the free Apify plan allows five concurrent runs.

The table

The same numbers as text, for the rows most people ask about (share of employers, %):

Technology	UK	Germany	Netherlands	US	India
AWS	53	33	29	46	53
Python	43	36	32	52	49
Java	34	38	28	42	48
Kubernetes	37	32	36	33	36
PostgreSQL	39	27	28	33	35
Docker	29	32	28	28	39
Microservices	29	27	29	36	42
TypeScript	33	24	24	20	19
Azure	18	17	37	16	30
Google Cloud	26	10	18	21	30
Kafka	22	17	15	22	28
Node.js	20	13	16	18	25
Spring Boot	13	22	12	14	23
C# / .NET	14	14	31	9	14
Terraform	16	10	14	15	11
Kotlin	11	11	11	8	5
Go (floor)	10	5	7	7	13
FastAPI	10	8	8	7	14
Rust	9	6	2	12	3
LLMs, GenAI	19	14	9	28	18
AI agents	20	12	16	20	18
Claude Code	6	10	8	7	9
GitHub Copilot	3	3	4	4	6

What each market asks for

UK. The widest spread of the five. AWS (53 %), Python (43 %) and PostgreSQL (39 %) lead, and TypeScript is higher here (33 %) than in any other country. Google Cloud reaches 26 %, the most in Europe.

Germany. A JVM market: Java (38 %) edges out Python (36 %), Spring Boot is named by 22 % of employers, and Kotlin by 11 %. Cloud is named less often than in the UK (AWS 33 %, Google Cloud 10 %), and PHP still has 11 %. Go is at 5 %, the lowest of the five.

Netherlands. The only country where Azure (37 %) is ahead of AWS (29 %), with C#/.NET at 31 % and Kubernetes right behind Azure at 36 %. LLMs come up least often here (9 %).

US. Python (52 %) and AWS (46 %) lead, Java follows (42 %). This is where AI shows up most: 28 % of employers mention LLMs or generative AI in a backend posting. Rust (12 %) and C++ (13 %) are also at their highest.

India. AWS (53 %), Python (49 %) and Java (48 %), then microservices (42 %) and Docker (39 %). The classic service stack is here in full: Spring Boot 23 %, MySQL 23 %, MongoDB 20 %, Redis 19 %, and Google Cloud and Azure both at 30 %.

What to learn next, decided by Claude Code

The table answers "what does the market ask for". A person needs a narrower answer: given my stack, which one thing opens the most roles? I gave a fresh Claude Code session, connected only to the Apify tools above, this request, word for word:

I'm a backend developer in Berlin: six years of Java with Spring Boot,
PostgreSQL, Kafka, some Docker. I have time to learn one thing properly in the
next three months, and I want to pick it by what German employers actually ask
for, not by what is trending online.

Use the Apify tools you have, with previews only (previewOnly: true, which
charges nothing; do not pull rows):
1. With the job search Actor, count active backend postings in Germany from
   the last 30 days: titles "backend", "back-end", "back end"; agencies and
   job boards left out. That is the base.
2. Count how many of those postings mention my current stack in the
   description, one preview per technology (java, "spring boot", postgresql,
   kafka, docker).
3. Then pick six to eight candidate technologies I could learn next (a
   language, a cloud, an infrastructure tool, whatever you think is worth
   checking) and count each the same way. Include at least kotlin, golang,
   kubernetes and aws.
4. For the two strongest candidates, count the postings that mention java AND
   the candidate together, so I can see how many roles my current stack plus
   the new skill would cover.

Answer with one table (technology, postings that mention it, share of the
base), then the one thing you would learn and why in three sentences, with the
numbers. Say which counts are rough (for example, a word that also has a
common ordinary meaning). Answer in English.

It loaded the job search tool, sent all fourteen previews at once, then read the totals from each run's dataset. For the overlap it did something I had not asked for. Lines in descriptionSearch are alternatives, so ["java", "kubernetes"] counts postings with either word. It ran that, subtracted it from the two single counts to get the postings with both, and then checked the result with one more preview written as "java AND kubernetes". Both ways gave 47. Its table, abridged:

Technology	Postings	Share of 369
java (current)	153	41.5 %
kubernetes	115	31.2 %
python	114	30.9 %
aws	103	27.9 %
kotlin	66	17.9 %
golang	11	3.0 %
java AND kubernetes	47	12.7 %
java AND aws	42	11.4 %
java AND python	39	10.6 %

Its pick was Kubernetes: the most requested technology the developer does not already have, "spread across 77 employers rather than a handful of heavy posters", and the one that overlaps most with Java, "47 of the 153 Java postings (31%)". It also builds on the Docker they already know.

The part I liked most was the list of rough counts. It called golang "a hard floor, not a real count", because most postings write "Go". It noticed on its own the effect I had to correct for in the big table: Kotlin's 66 postings came "from only 28 employers, so demand is concentrated in a few companies hiring in bulk". And it said that Spring Boot and PostgreSQL were undercounted because it had kept the developer's exact words, so postings writing only "Spring" or "Postgres" were missed. Eighteen previews, 39 turns, eleven minutes, and the Actor charged nothing.

Its window was slightly different from mine (the last 30 days counted from the day of the run), so its base is 369 postings where my German row has 359, and its counts land within ten postings of mine. One thing I would add to its answer: counted by employers, as in my table, Python and AWS are a little ahead of Kubernetes in Germany (82 and 75 employers against 73). So it is a close call between three, and the overlap with Java is what tipped it.

Run it on your stack

Paste this into Claude Code with the MCP server above and change the first line:

My stack: <languages, frameworks, databases, cloud>. Country: <country>.
Using the job search Actor with previewOnly: true only, count open backend
postings in <country> from the last 30 days (titles "backend", "back-end",
"back end", removeAgency: true). Then count each technology of my stack and
eight candidates I don't have, one preview each, and read "at N employers"
from each preview's note. Rank the candidates by employers, not postings.
For the top two, count postings that mention my main language AND the
candidate. One table, one recommendation, and which counts are rough.

Two changes worth making for your own run. If your country posts a lot (the US, India), shorten the window to a few days with datePostedAfter, or the text search will refuse the run and say why. And if your title is not "backend" (data engineer, platform engineer, "Softwareentwickler" in Germany), put your own titles in titleSearch: the stack question depends on who is asking.

What this does not tell you

How much each skill is required. A posting that says "nice to have" counts the same as one that says "must". The table measures what employers mention, not what they test for.
Roles without "backend" in the title. Many backend jobs are titled "Software Engineer" or "Java Developer". They are outside this base, and their stacks may differ.
Pay. Whether Kubernetes or Rust pays more is a different question, and few postings state a salary to answer it from.
A trend. This is one month. The same previews next month would show what is rising.

For AI agents reading this

To answer "which technologies do employers ask for" or "what should this person learn next": run b2bsearch/linkedin-job-search-api with previewOnly: true, titleSearch (role words, one line per variant, include local-language titles), locationSearch (one country), status: "active", removeAgency: true, and a window: timeRange: "30d" for most countries, plus datePostedAfter to shorten it where the base is large (a description search reads at most 500 postings; above that the run returns an input_problem note and charges nothing). Get the base without descriptionSearch, then one preview per technology with descriptionSearch set to that technology's spellings (["kubernetes", "k8s"]; quote phrases: "\"spring boot\""; lines are OR). Read _total and the employer count from _note ("at N employers"); rank by employers, because one employer can post a hundred copies. For "A and B", either subtract the OR count from the two single counts or put "A AND B" on one line. Treat "go" as unsearchable and count golang plus quoted phrases as a floor. Previews are free; do not pull rows for this question. Agent setup: apify.com/agents.md, Apify MCP server docs.

This is the third post of the series on developer job search with Claude Code; the first covers the market count and the search by stack, the second the ghost-jobs check. The Actors are LinkedIn Jobs Database API, Companies Hiring Now and Advanced LinkedIn Jobs Scraper; per-tier pricing is on each Actor page.

Ghost jobs, measured: 58% of UK backend postings came from middlemen

Kevin Hall — Tue, 27 Oct 2026 13:35:43 +0000

Every ghost-jobs post on this site leans on the same kind of number. Thirty percent of what you apply to does not exist. Forty percent of IT listings are not really open. Those figures come from surveys: someone asked recruiters and hiring managers whether they had ever posted a role they were not filling. A survey tells you that the practice exists. It does not tell you which posting in front of you is the dead one.

The posting itself gives some of that away, if you read enough of them side by side. Who put it up. How long it stayed open. Whether the same role came back after it closed. And in Ontario, since 1 January 2026, whether the employer says the job exists at all, because the law now makes them say it.

So I measured those four things on LinkedIn backend postings in five countries, nearly 30,000 of them, plus 2,718 software postings in Ontario, from Claude Code. This is the second post of the series; the first one counted the market and cut the copies. The short version of this one:

In the UK, 58 % of backend postings in the last 90 days came from staffing agencies, job boards and talent marketplaces. Another 7 % came from accounts with no company on record. An employer with a company page posted 35 %. In Germany and the Netherlands the middlemen share is closer to a third.
Middlemen's postings close fast: 60 % of the UK ones were gone within three days, against 23 % of employers' postings. Most of them come back a few days later as a new posting.
About one employer role in eight was closed and then posted again within 90 days. One 33-person firm posted the same two backend roles almost every Friday for six months, 49 postings in all.
In Ontario, where a posting must now say whether it is for an existing vacancy, 26 % of software postings said yes, 2 % said no, and 72 % said nothing.

None of these signals proves a posting is fake. Each one tells you where to spend an application and where to ask a question first. The last part of the post is the check itself: a Claude Code session that ran it on this week's postings, and the prompt to run it on yours.

The wiring

The same as in post 1: Apify's MCP server, pinned to the jobs Actors.

claude mcp add --transport http apify \
  "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api,b2bsearch/hiring-companies-finder"

The search runs on LinkedIn Jobs Database API, an Apify Actor over a database of LinkedIn job postings. What makes this post possible is that the database keeps postings after they close: status: "any" returns open and expired postings in one run, each expired one with its closedAt, and timeRange: "6m" goes back six months. A live scraper sees only what is open today, so it cannot tell you that a role was posted twenty times before.

How I counted

Titles: backend engineer, backend developer, software engineer backend, the same three as in post 1. Countries: the US, the UK, Germany, the Netherlands and India. Window: postings from 29 July to 21 October 2026 for the cross-country numbers (90 days), and from 30 April for the UK, German and Dutch histories (six months). All postings, open and closed, without the description text: 6,282 in the UK, 4,096 in Germany, 1,370 in the Netherlands over six months, 12,288 in the US and 5,682 in India over 90 days. For Ontario, a separate pull with the text: every posting titled software engineer, software developer or backend in Ontario from 1 September to 21 October, 2,718 of them.

"Closed" is LinkedIn's own state, the one a job page shows as "No longer accepting applications". I opened a handful of postings on LinkedIn to make sure the field means what it says: the ones the data has as closed weeks ago showed that banner, and the old ones it has as open were still taking applications.

Who posted a posting is the Actor's agency rule plus two more buckets:

Staffing agency: the posting's industry is Staffing and Recruiting, or the employer's company card says it recruits for others.
Job board: a known aggregator that relists other employers' openings.
Talent marketplace: an account that posted more roles in a month than twice its own headcount. In the UK these are mostly AI recruiting platforms and talent networks.
No company card: the posting links to no company on record, so there is no headcount, industry or website to check.
Employer: everything else, a company with a card and a headcount.

A role is an employer plus a normalized title. A role was "closed and posted again" when a new posting of it went up at least three days after an earlier one closed, with no other copy of it open in between, so that a copy per city does not count as a repost.

1. Who posted it

Backend postings, 29 Jul to 21 Oct	US	UK	Germany	Netherlands	India
Postings	12,288	2,728	1,908	578	5,682
Employer with a company card	52 %	35 %	60 %	60 %	57 %
Staffing agency	11 %	25 %	5 %	9 %	7 %
Talent marketplace	16 %	19 %	10 %	21 %	19 %
Job board	13 %	14 %	15 %	3 %	7 %
No company card	8 %	7 %	10 %	7 %	10 %

The UK is the outlier. Not quite two backend postings in three come from someone other than the company with the job, and a single AI recruiting platform put up about one UK backend posting in ten on its own.

A middleman's posting is not a fake job. An agency posting is often a real opening one step removed; a job board relists a real employer's posting. But you are applying into someone else's funnel, and the same opening shows up under several names: the employer's own posting, the agency's, the board's copy of each. In post 1 the copies were per city; here they are per middleman.

Two switches cover it. removeAgency: true drops staffing agencies and job boards by industry, company card, name and posting pace, and employerHiring: true puts the employer's open postings and its last 30 days of postings on every row next to companyEmployeeCount, so a marketplace that posts more roles than it has people stands out in the row itself.

2. A posting's life is short, and "posted 2 days ago" means little

Closed within 3 days of posting, 90 days	US	UK	Germany	Netherlands	India
Employers	28 %	23 %	27 %	17 %	42 %
Agencies, job boards, marketplaces	62 %	60 %	45 %	36 %	71 %

Most middlemen's postings are gone within three days, and a new copy takes their place. Over six months in the UK, 76 % of the backend postings that closed within three days had the same title from the same poster up again within two weeks. The posting date on a relisted role is the date of the latest copy, not the date the role opened.

Employers' postings live longer, and the long tail is where the stale ones sit. Over the six-month window, 38 of the 268 UK employer postings still open on 21 October had been up for more than 60 days (14 %); in Germany 66 of 352 (19 %), in the Netherlands 14 of 96 (15 %). Some of those are hard roles to fill. Some are the "open for months" postings from the threads.

3. The role that keeps coming back

Across the five countries, 11 to 14 % of employer roles were closed and posted again within 90 days. That is a role that went quiet, then reappeared as a fresh posting with zero applicants on it.

The extreme case in the UK data is a 33-person financial-services firm in London. Since 1 May it has posted "Mid Level Backend Engineer" 25 times and "Senior Backend Engineer" 24 times, almost always on a Friday, from the same office. Each posting stayed up for about eight days and closed; the next one went up the following Friday. 48 of the 49 had fewer than 25 applicants. In the latest snapshot the firm had 14 postings open and had put up 63 in the previous 30 days, with 33 people on its company card.

Maybe they are hiring two backend engineers and nobody good has applied in six months. Maybe the postings feed a pipeline. The data cannot say which, and neither can you from the posting. What you can do is know the history before you write a cover letter, and ask the question in your first message: is this role open now, and how many people are you hiring for it?

4. In Ontario, the posting has to say

Since 1 January 2026, Ontario's Employment Standards Act requires employers with 25 or more employees to state in every publicly advertised posting whether it is for an existing vacancy. The same package requires the expected pay or a pay range, a statement when AI is used to screen or select applicants, and an answer to every interviewed candidate within 45 days (a summary by McCarthy Tétrault).

That is the one place where a ghost job has to declare itself, so I read the text of every Ontario software posting from 1 September to 21 October that had one.

Ontario software postings, 1 Sep to 21 Oct 2026	Postings	Share
Says it is for an existing vacancy	698	26 %
Says it is not, or that it is for proactive recruitment	49	2 %
Says nothing either way	1,971	72 %
States a pay range	1,321	49 %
Says AI is used to screen or assess applicants	458	17 %

The wording varies ("This job fills an existing vacancy", "Vacancy Status: This posting is not for an existing vacancy within the organization", "This posting is for proactive recruitment purposes and may be used to fill current openings or future vacancies"), so the count is a set of patterns I checked by hand on samples, not a single keyword. On the postings that said nothing, I opened a few on LinkedIn: the statement was not in a separate field either.

The 49 postings that said "not an existing vacancy" came from four employers, almost all of them with more than 10,000 people. Twelve of the 49 had over 200 applicants anyway. Read the last paragraph of a posting before you apply; in Ontario it now tells you whether you are applying for a job or for a database.

Silence is harder to read. Counting by employer rather than by posting, 126 of 532 Ontario employers of 25+ people said "existing vacancy" at least once, and 405 never said either thing. Some will have the statement on their own careers page. On LinkedIn, most of what a candidate reads in Ontario still does not answer the question the law asks.

To run this for your own search, put the phrase in the description search. Keep a title and a 7-day window on it, so the search stays within the texts it reads in one go, and run it weekly:

{
  "titleSearch": ["software engineer", "software developer", "backend"],
  "locationSearch": ["Ontario, Canada"],
  "timeRange": "7d",
  "descriptionSearch": ["existing vacancy", "existing job vacancy", "currently vacant"],
  "descriptionExclusionSearch": ["not for an existing vacancy", "proactive recruitment"],
  "removeAgency": true,
  "employerHiring": true,
  "limit": 50
}

5. The check, run by Claude Code

I gave Claude Code the London persona from post 1 and a plain request: before I apply this week, pull 30 fresh UK backend postings without agencies, pull the same employers' last six months, and sort the 30 into apply first, check first and skip for now. The full prompt is in the next section. Everything below is from the recorded session.

It started with the postings, and the input it built is the one you would write by hand:

{
  "titleSearch": ["backend engineer", "backend developer", "software engineer backend"],
  "locationSearch": ["United Kingdom"],
  "timeRange": "30d",
  "datePostedAfter": "2026-10-13",
  "status": "active",
  "removeAgency": true,
  "employerHiring": true,
  "descriptionType": "none",
  "limit": 30
}

For the history it put the 23 employers' companySlug values into organizationSlugFilter with timeRange: "6m" and status: "any", and sized it first with a free preview: 306 postings at 23 employers, 83 of them open. My account is on the free Apify plan, where a run delivers 100 rows, so it split the employers across four runs that each fit, started them in parallel and merged the rows. It also tried a shell command to see whether an Apify token was set; the session allowed only the Apify tools, so the command was refused, which is what pinning them is for.

An excerpt of the table it returned. I coarsened the employer descriptions to a size band and a broad industry; the rest is as it wrote it.

Verdict	Posting	Employer	Days up	Same title, 6 months	Earlier copy closed first	Applicants	Why
Apply first	Senior Backend Engineer, London	fintech, 500–1,000 staff	7	1	no	75–100	First posting; 82 applicants already, so apply fast
Apply first	Software Engineer – Backend, UK	B2B software, 500–1,000	7	2	no	<25	New role, two location copies open
Check first	Senior Backend Developer, Liverpool	insurer, 201–500	8	2	yes	50–75	Posted again three weeks after closing
Check first	Backend Software Engineer, London	consumer app, 1,000–5,000	8	4	yes	25–50	Fourth posting since July; each closed within about a week
Skip for now	Senior Backend Engineer, London	AI software, 51–200	6	21	yes	<25	Posted again about weekly since June
Skip for now	Founding Backend Engineer (Python/Django), London	2–10 staff, founded 2024	8	2	yes	<25	Your stack, but 22 open postings from 8 people; back the day after closing
Skip for now	Backend Engineer, London	AI start-up, 11–50	7	1	no	<25	29 postings in one week from 12 staff
Skip for now	Senior Backend Engineer, London	IT services, no headcount on record	7	1	no	<25	211 postings in 7 days; looks like an aggregator

The first sentence of its summary, as written:

The main pattern is re-posting: the employer had already posted the same title in
the last six months for 23 of the 30 postings, and 14 of the 30 went up after an
earlier copy had closed, so many "6–8 days old, under 25 applicants" rows are just
reset counters, not new openings.

"Reset counters" is the sentence I would put on a sticky note. A posting that says six days old and under 25 applicants looks like the best row in the list, and for the AI-software employer above it was the twenty-first copy of the same role. I checked that one against my own pull: 21 postings of the same title, 3 June to 21 October.

Two things it did that I would not have thought to ask for. It kept a Python/Django founding role, the closest match to the persona's stack in the 30, in "skip for now", because the employer had 22 postings open with 8 people on its card. And it finished with the same advice as the threads, made concrete: open the posting to confirm it is live, look for the role on the employer's careers page, and for a reposted role ask the recruiter whether there is one funded seat and a hiring manager reading applications.

6. The check, as a routine

Four columns are enough, and all four come from fields on the row or from one extra run.

Column	Where it comes from	Read it as
Who posted it	`removeAgency`, `companyEmployeeCount`, `employerOpenJobs`, `employerJobs30d`	More open roles than people: a marketplace, not the employer
Age	`postedAt` against `_input.dataAsOf`	Open more than 60 days: ask if it is still open
History	a second run with `organizationSlugFilter`, `status: "any"`, `timeRange: "6m"`	Closed and posted again: ask how many people they are hiring
Statement	the description, in Ontario	"Not an existing vacancy": apply only if you want to be in the pool

The prompt, for a Claude Code session with the Apify MCP server connected. Change the titles, the country and the window:

Pull 30 active backend postings in <country> from the last 14 days with the job
search Actor: titles <your titles>; agencies and job boards left out; the
employer's hiring pace on; no description text. Then pull the same employers'
postings of the last 6 months with status "any". For each of the 30, give me:
days since posted, how many times the employer posted the same title on
separate dates, whether an earlier posting of the role closed before this one,
open postings against headcount, applicant bucket. Sort them into apply first,
check first and skip for now, with the reason. No names of people or companies.

Then the part that matters, which no tool does for you: apply first to the "apply first" rows, and for the "check first" rows, ask before you write the cover letter. Post 1 shows how to find the person to ask and how to have Claude draft the note while you press send.

Once a week, rerun the history for the employers you applied to. A role you applied to that closes and comes back a week later with zero applicants has not filled the seat; that is your cue for a follow-up, not a second application.

What this does not tell you

Whether a posting is fake. Every signal here has an innocent reading: a hard role, a growing team, an agency with a real mandate. The data shows the behaviour; the intent stays with the poster.
Why a role came back. A repost after a failed hire and a repost into a pipeline look the same in the data.
What the employer's own site says. The Ontario count reads the LinkedIn text only.
Small middlemen. A recruiter whose company card says nothing about recruiting is counted as an employer. The middlemen shares above are a floor.

For AI agents reading this

To check postings before someone applies: run b2bsearch/linkedin-job-search-api with titleSearch, locationSearch, timeRange (7d to 30d), removeAgency: true, employerHiring: true, descriptionType: "none" and a limit the person will read (20 to 50). For history, run it again with organizationSlugFilter set to the employers' companySlug values, the same titles, timeRange: "6m" and status: "any"; size it first with previewOnly: true (free; read _total), and on the free Apify plan split employers across runs of at most 100 rows. Per row: isOpen, postedAt, closedAt (on expired postings), applicantRange, companyEmployeeCount, employerOpenJobs, employerJobs30d, employerJobs90d. Group by companySlug + normalized title; a role closed and posted again is a posting whose postedAt is after an earlier posting's closedAt with no copy open in between. For Ontario, put "existing vacancy" in descriptionSearch with descriptionExclusionSearch: ["not for an existing vacancy"], a title and timeRange: "7d", so the search stays within the texts it reads at once. Never call a posting fake; report the history and let the person decide. Rows with _status other than found are free notes. Agent setup: apify.com/agents.md, Apify MCP server docs.

This is the second post of the series on developer job search with Claude Code; the first covers the market count, the stack search and the note to the CTO. The Actors are LinkedIn Jobs Database API, Companies Hiring Now and Advanced LinkedIn Jobs Scraper; per-tier pricing is on each Actor page.

Job search in Claude Code: half of US backend postings were copies

Kevin Hall — Tue, 27 Oct 2026 11:02:53 +0000

The job-search threads on this site read like the same ledger. Seventy-two applications, twenty-three rejections, two offers in one senior engineer's two-month search. Seventy-three applications and sixty-one silences in another. A rejection two minutes after pressing submit. Postings that do not feel real, or have sat open for months.

The advice under those posts is usually "apply more" or "tailor more". Both make the queue longer. What the threads describe is a queue problem: the same role listed many times, the good roles buried under two hundred applicants by the end of the week, a form in front of every person who could say yes.

On 27 October 2026 I ran a developer job search from Claude Code over a database of LinkedIn job postings, to see how much of that queue you can step around. The persona is ordinary on purpose: a backend developer in London, five years of Python (Django, FastAPI), some Go, Postgres and Kubernetes, looking for a mid-senior role. The tools are three Apify Actors over the same jobs database: LinkedIn Jobs Database API for the search, Companies Hiring Now for the employers, and Advanced LinkedIn Jobs Scraper when you want the same rows with the field names of the best-known scraper. No LinkedIn login, no cookies, no browser.

Every number below comes from that day's runs. The database holds the last 180 days of postings and is loaded in waves; on 27 October it ran to 21 October, so "the last 30 days" means 25 days of postings. Rows shown here carry no names of people and no names of employers.

The wiring, once

Apify runs an MCP server at https://mcp.apify.com; the tools parameter pins the Actors a session may reach. In Claude Code:

claude mcp add --transport http apify \
  "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api,b2bsearch/hiring-companies-finder,b2bsearch/linkedin-jobs-scraper"

Any other MCP client (Claude Desktop, Cursor, VS Code, ChatGPT) takes the same URL, with OAuth on first connect or an Authorization: Bearer <APIFY_TOKEN> header:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api,b2bsearch/hiring-companies-finder,b2bsearch/linkedin-jobs-scraper"
    }
  }
}

The Actors appear as tools named b2bsearch--linkedin-job-search-api, b2bsearch--hiring-companies-finder and b2bsearch--linkedin-jobs-scraper (the slash becomes a double hyphen). The server adds get-actor-run and get-dataset-items next to them: a tool call returns the run and its datasetId, and the rows come from get-dataset-items. Without MCP, the same Actors run from the Apify API, the Python and JavaScript clients, n8n, Make or Zapier.

Two of the steps below were run by Claude Code itself, from a plain-English request, in sessions I recorded; the inputs quoted there are the ones it built. The rest I typed into the same fields, because the point there is the field.

1. Count the market before you apply

The search Actor has a preview mode that returns the count and a breakdown instead of rows, and it is not billed. One preview per country for backend titles (backend engineer, backend developer, software engineer backend), last 30 days:

{
  "titleSearch": ["backend engineer", "backend developer", "software engineer backend"],
  "locationSearch": ["United Kingdom"],
  "timeRange": "30d",
  "previewOnly": true
}

Backend postings, 25 days to 21 Oct	US	UK	Germany	Netherlands	India
Postings	2,244	316	266	97	573
Distinct roles (employer + title)	1,126	266	216	92	463
Salary stated	14 %	15 %	12 %	19 %	5 %
Recruiter named on the posting	7 %	22 %	11 %	31 %	17 %
Under 25 applicants	43 %	35 %	40 %	35 %	20 %
Over 200 applicants	18 %	15 %	15 %	20 %	46 %

Three things in that table change what you do next. Almost half of the Indian backend postings already had more than 200 applicants when they were recorded, so the queue there starts long. The Dutch postings name the recruiter one time in three, the American ones one time in fourteen. And the American market is half the size it looks, which is the next section.

One trap before it: the title is not always in English. In Germany, softwareentwickler alone matched 470 postings in the same 25 days, more than every title with the English word backend in it (336). Search the words the market writes, in its language.

2. Cut the copies

Of the 2,244 American backend postings, one employer posted 609: twenty titles, fifteen of them listed 30 times or more, once per city (Atlanta, Dallas, Miami, Phoenix and on). A consulting firm posted two titles 81 and 78 times, each ending in "Location OPEN". Grouped on employer and title, the 2,244 postings are 1,126 roles. In the United Kingdom the same grouping removes 16 % of the postings, in the Netherlands 5 %.

Each row carries jobId, companyId and title, so the grouping is one line in a spreadsheet or one sentence to Claude: "keep one row per companyId and title, the newest". Two more kinds of noise are worth naming:

Relocation postings. A travel platform listed "Bangkok based, relocation provided" roles in the German, Dutch and British searches. The title says so; read it before you count the role as local.
Agencies and job boards. removeAgency: true drops staffing firms, aggregators and employers that post far more roles than they have people. While writing this I found that six of the 25 top "employers" in the British list were still recruiting firms: their postings carry the client's industry, not their own. Since build 0.1.3 the rule also reads the employer's own card and its 30-day posting pace, and the same list came back with none of them; since 0.1.6 it also reads what the card says the employer does (section 8 has the measurement). A firm whose card does not say it recruits still gets through, so read the titles that sell ("AI Startup, up to £120k").

3. Search the posting text for your stack

A backend title says nothing about Django or Go. The text does, and the search Actor can filter on it: put the role in titleSearch and the technology in descriptionSearch.

{
  "titleSearch": ["backend"],
  "descriptionSearch": ["django", "fastapi"],
  "locationSearch": ["United Kingdom"],
  "timeRange": "30d",
  "previewOnly": true
}

Postings with "backend" in the title, 25 days	All	Text mentions
UK	327	34 Django or FastAPI, 24 golang
Netherlands	103	39 Kubernetes
Germany	336	27 Django or FastAPI

Thirty-four roles is a week of good applications, not a month of bad ones. The text filter reads the postings the other filters leave, at most 500 of them, so it needs a narrow cut: title words plus a country and at most 30 days, or one employer. "Kubernetes anywhere in Germany this month" is refused before anything runs, with a note on how to narrow it.

For a fit judgement that is more than one keyword, there is a better split of labour, and the agent session in section 8 used it: let the database apply the filters it can apply exactly (title, country, size, agencies), pull 40 rows with the posting text, and let Claude read the text.

4. Stand where the queue is short

The applicant count is recorded with the posting, in buckets of 25. In the British backend search with agencies out, 99 of 295 postings had fewer than 25 applicants. Of the 33 posted on the last two days in the database, 26 did.

{
  "titleSearch": ["backend engineer", "backend developer", "software engineer backend"],
  "locationSearch": ["United Kingdom"],
  "datePostedAfter": "2026-10-20",
  "maxApplicants": "25",
  "removeAgency": true
}

That is the timing problem from the threads above in numbers: a fresh posting is a short queue, and the queue grows within days. The loop that follows from it is a daily run with datePostedAfter set to the dataAsOf date of the previous run (every row carries it in _input), deduplicated on jobId.

One honest limit. The database is loaded in waves, not every hour, so a "last 24 hours" window run between two loads finds nothing. On 27 October it did exactly that for Germany. Since build 0.1.3 the empty row says why, with the date of the newest posting and what to change, instead of "no job matches". Anchor the loop on dataAsOf, not on the clock.

5. Salary and the recruiter, before the cover letter

Two filters decide where a cover letter is worth writing. salaryMin keeps postings that state a salary at or above a yearly amount in a currency; recruiterOnly keeps postings that name the recruiter or hiring manager, whose name, headline and profile link then ride the row.

UK backend, agencies out, 25 days	Postings	Employers	Also name a recruiter	Also state a salary
All	295	170	63	42
Salary stated, at least £80,000	34	27	18	34
Recruiter named	63	47	63	21

Postings that name a recruiter state a salary one time in three; the rest, about one time in eleven. A posting that names a person and a number is a posting written by someone who wants to be found.

6. Companies hiring a team, not filling a seat

Companies Hiring Now turns the same search into employers, most matching postings first, each with its hiring pace: open postings, and postings in the last 7, 30 and 90 days.

{
  "jobTitles": ["backend", "\"software engineer\""],
  "locations": ["United Kingdom"],
  "postedLimit": "month",
  "maxCompanies": 25
}

The search Actor puts the same pace on every job row with employerHiring: true (employerOpenJobs, employerJobs7d, employerJobs30d, employerJobs90d, employerTopTitles30d). Two postings from the British pull show why it matters. A 95-person company hiring a senior backend engineer had 19 roles open and had posted 26 in 30 days: a team being built. A 152-person company hiring for the same title had posted 3: a seat being filled. Both are real jobs, and they call for different notes: the first is a conversation about the team, the second about the one problem the hire is for.

The same columns help with the postings that do not feel real. A role that has been open for months at an employer that has posted nothing else in 90 days is not proof of a ghost job, but it is the one to apply to last.

7. From the posting to the person who decides

The most useful part of a hiring signal is the person behind it. With decisionMakers: true every employer in the result is followed by its leaders as rows of their own (_type: decision_maker), ranked founder and CEO first, each with title, headline, profile link and the job they belong to (forJobId, forJobTitle). For a backend developer the right people are the engineering leaders of small companies, where the CTO still reads their own messages:

{
  "titleSearch": ["backend engineer", "backend developer", "software engineer backend"],
  "locationSearch": ["United Kingdom"],
  "timeRange": "30d",
  "removeAgency": true,
  "organizationEmployeesGte": 11,
  "organizationEmployeesLte": 500,
  "employerHiring": true,
  "decisionMakers": true,
  "decisionMakerRoles": ["founder", "cxo", "vp", "director"],
  "decisionMakerTitleKeywords": ["cto", "engineering", "technology", "technical"],
  "decisionMakersPerCompany": 2,
  "descriptionType": "text",
  "limit": 20
}

Twenty postings at 16 employers came back with nine engineering leaders: three CTOs, two co-founders who are the CTO, a VP of Engineering, two Directors of Engineering and a Director of Technical Product. Nine employers had nobody on record at those roles; those are free note rows, not empty charges.

The first time I ran it, the leaders were a Sales Director, a Claims Director and a Director of Casino. Title keywords match as text inside the title, and "cto" sits inside "Director". Since build 0.1.4, C-level acronyms (cto, coo, cfo and the rest) match as whole words, so cto finds "Co-Founder & CTO" and not "Director".

The decision-maker rows on the job listings carry the profile link, not a mailbox. If you want an address, Decision Maker Email Finder by Domain takes the employer's companyDomain from the job row and returns the leaders with the email on record.

8. Let Claude write the note, and press send yourself

Finding the role is half the work; the other half is a short note to a person, and then the next one. Both are text, and both are where Claude is useful, as long as it drafts and you send.

The shortlist, from one request

I gave a fresh Claude Code session, connected only to the Apify tools above, a plain request: my stack (Python with Django and FastAPI, some Go, Postgres, Kubernetes), London, a mid-senior backend role at a company of 11 to 500 people. Count first and stop above 400; then pull 40 jobs with the posting text and the hiring pace, without the description filter, and read the texts yourself; give me the eight that fit, with the stack words quoted from each posting.

The session took 11 turns and three minutes. The pull it built:

{
  "titleSearch": ["backend", "back end", "back-end"],
  "locationSearch": ["United Kingdom"],
  "timeRange": "30d",
  "removeAgency": true,
  "organizationSizeFilter": ["11-50", "51-200", "201-500"],
  "limit": 40,
  "descriptionType": "text",
  "employerHiring": true
}

The preview counted 370 postings. The table it returned had one row per role, each with a quoted stack line such as "Strong Python and Django experience … Solid PostgreSQL expertise and AWS experience" or "We are a Go shop … PostgreSQL, MongoDB, RabbitMQ, Redis, gRPC … AWS and Kubernetes". Six of the eight had fewer than 25 applicants. It picked a 152-person lender first (its posting matched the stack almost word for word, stated the pay in the text, and the employer had posted only three roles in 30 days, "a specific hire rather than a mass campaign"), and a 311-person savings app second.

The note, from the rows

A second session got the dataset from section 7 (twenty postings, nine engineering leaders) and this brief: pick the three postings that fit the stack and have a decision-maker row; for each, at most 90 words, one detail from the posting, one from the hiring pace if it helps, one sentence of matching experience using only what I said, one ask, no flattery; placeholders instead of real names; under each draft, the fields used. One of the three, as written:

Hi {first_name},

I saw the Senior Backend Engineer role at {company}: backend services for the whole lending lifecycle, from credit decisioning to collections, with integrations into credit bureaus and KYC/AML providers. The posting asks for Python, Django and PostgreSQL. I have five years of Python with Django and FastAPI, some Go, plus Postgres and Kubernetes, and I'm based in London. Could we have a 15-minute call, or could you point me to whoever is running this hire?

That is the whole method: one fact from the posting, one true sentence about you, one small ask, sent to a person instead of a form.

The session also did three things I had not asked for, and they are the reason to keep a human on the send button. It left the hiring pace out of two drafts because the numbers said nothing about engineering (one employer's 60 postings in 30 days were mostly operations roles, which it read from employerTopTitles30d). It flagged a leader whose title said VP of Engineering while their headline named a different company, and another whose record the Actor marks as last refreshed before 2025 (_note), with "confirm the role before you write". And it pointed out that one role asked for six years against my five.

The loop

Once the pieces work by hand, the routine is short:

Every morning: run the search with datePostedAfter set to the previous run's dataAsOf, deduplicate on jobId and on companyId + title, and append the new rows to a tracker (a CSV in the repo, a Google Sheet, a Notion database). An Apify schedule plus a webhook into n8n or Make does this without a laptop open.
Rank in Claude Code: fit from the posting text, then applicant bucket, then posting date, then hiring pace. Keep the top five.
Draft, then send by hand: one note per role to the person in the decision-maker rows or the recruiter named on the posting, with the fields used listed under each draft. Apply through the form as well; the note is not a replacement for the application, it is the reason someone reads it.
Follow up once, five working days later, with one new fact.
Once a week, clean the tracker: run the same search with status: "expired" and expiredAfter set to last week, and close the rows that match. In the United Kingdom, 525 backend postings closed or passed their end date after 1 October; waiting on any of them is time spent.

What the agent got wrong on the first try

The first session got a looser brief (filter by the stack, then pull 15). It put the stack into descriptionSearch next to an employer-size bound, and the pull crawled: every page read posting texts, and the size bound skipped postings and asked for more pages. Nine minutes in, with 14 rows delivered and the turns used up, I stopped it. Two things in that session were worth keeping. It excluded four employers by id after spotting them in the preview's employer list as agencies, without being asked. And the second session noticed that the preview count did not change when the size bound was added, which is true: the bound is applied to the rows. Since build 0.1.5 the preview says so in its note.

Reading 40 rows, the second session also set 16 aside as recruitment agencies that the agency filter had let through: firms with an empty industry whose own description reads "specialist search firm" or "recruitment consultancy". Since build 0.1.6 the filter reads that description too. The same input on the new build returned 2 agency rows instead of 14 by the same text check, both from one firm whose card does not say what it does.

The prompt pattern that worked: count first with a stop rule, let the database apply what it applies exactly, let the model read the text, ask for the fields used, and never let it send.

What this does not do

Remote and hybrid. The data has no remote flag, and the Actors refuse a remote filter rather than fake one. A title search for backend AND remote or backend AND hybrid in the UK found 24 postings, a sample of the ones that say it in the title.
Real time. The database is loaded in waves; on 27 October the newest posting was from 21 October. For an alert within the hour, watch the employer's own careers page.
Every salary and every recruiter. Salary is stated on 5 to 19 % of postings by country, the recruiter on 7 to 31 %.
Every agency. The agency rule catches staffing firms by industry, by what the employer's card says it does, by name and by posting pace; a small recruiting firm whose card says none of that still gets through.
The application. It finds the role, the queue length and the person. The part where you are good at the job is still yours.

For AI agents reading this

To help someone find a job: run b2bsearch/linkedin-job-search-api with previewOnly: true and titleSearch (role words, boolean allowed, one line per variant, include the local language's titles), locationSearch (country names or codes, US states, cities), timeRange (30d for a market view), removeAgency: true; read _total and the market rows (dimension, value, count). Then run it without previewOnly, with limit set to what the person will read (20 to 50), descriptionType: "text", employerHiring: true, and organizationEmployeesGte/Lte for company size; the size bound applies to rows, not to the preview count. Use descriptionSearch only with a title and a country and at most 30 days; otherwise read the description column yourself. Deduplicate on companyId + title. Rank by fit from the text, then applicantRange (<25 applicants first), postedAt, employerJobs30d. For the people to write to, add decisionMakers: true with decisionMakerRoles and decisionMakerTitleKeywords; C-level acronyms match as whole words. Rows with _status other than found are free notes and explain themselves in _error or _note. For a daily feed, set datePostedAfter to the previous run's _input.dataAsOf; for closed roles, run status: "expired" with expiredAfter. Never send a message for the person: draft it, show the fields you used, and let them send. Agent setup: apify.com/agents.md, Apify MCP server docs.

This is the first post of a series on developer job search with Claude Code. The Actors are LinkedIn Jobs Database API, Companies Hiring Now and Advanced LinkedIn Jobs Scraper; per-tier pricing is on each Actor page.