GTM signals from career data: querying a B2B people database from the API, Claude Code and n8n

Every outbound team I talk to in 2026 runs on the same signals: the same intent feed, the same funding alerts, the same "new VP of Sales" notification on the same morning. A signal everyone receives at once is not an edge, it is the floor. The teams that still get replies define their own signals, size them against the whole market before pulling a row, and refresh the list on a schedule instead of exporting it once.

That job has a title now, GTM engineer, and it is mostly a data job. You need a B2B people database you can query by title, seniority, employer, employer size, past employer, country and, above all, by dates: when the current role started, when the person left the previous company, whether they have a current role at all. Then you need to run those queries from where you already work: a terminal, an AI agent, an n8n canvas.

I came to this from the developer side. I can read a JSON schema and a dataset, and that turned out to be most of what signal-based outbound needs. This series is the playbook I wish I had: one Actor, four ways to call it, three signal lists built end to end, with the inputs, the run logs and what the rows looked like.

The unit of work: a person row, three modes

The unit is a person row: name, current title and seniority, employer with size and industry, location, when the role started, and flags for whether an email is on record. On Apify each delivered row is a metered event, and the two aggregate modes return no rows at all.

For all three lists I use the LinkedIn People Search Actor by b2bsearch. Four properties make it fit this job:

• The filters are the primitives of signal-based selling, not a generic search box: past employer by domain with a left-after year, current role started after a given month, people between jobs, seniority buckets assigned from the title so that "CTO", "Chief Technology Officer" and "Head of Technology" land together, employer size and industry, a cap on people per company for account-based lists, and an exclusion of earlier datasets so a weekly run returns only new people.
• Counts and market breakdowns come back without rows. You see the size and the shape of a segment before a single row is delivered. TAM sizing stops being a project and becomes a habit.
• Whole markets are a normal list size. Every sales director in the US, UK and Germany who started a new role in the last twelve months is one query of 21,834 rows.
• Its limit is stated up front. Start dates reach the database when people update their profiles, so the most recent months are thin. Recency signals work as twelve-month windows, not thirty-day ones. Knowing that before you run is worth more than a prettier UI.

Mode and tier	What comes back
mode: "count"	The number of people matching the filters; no rows
mode: "market"	Breakdown by titles, employers, sizes, industries, countries, seniority and email coverage; no rows
mode: "people", profileDetail: "row"	Identity, current role, employer card, location, email flags
profileDetail: "profile"	The row plus the career: positions with dates, education, skills
profileDetail: "contacts"	The profile plus emails, phones and social links where one is on record

The habit that follows from this table: run count and market until the segment looks like the list you want, then switch mode to people. You never pull rows blind, and "the whole market" becomes a normal list size.

The three lists this series builds

Each starts with a question a revenue or investment team actually asks, is sized with the aggregate modes, then pulled and refined with real runs. Counts are from 2026-10-10.

#	The signal	Who uses it	Size
1	Left Google, Meta, Amazon, Microsoft, Apple, Salesforce, Oracle, Cisco, IBM or Intel in 2025 or later, now a founder or C-level (US, UK, DE, NL, CA)	Seed and angel investors, startup banking, cloud and dev-tools startup programs, incorporation and accounting services, recruiters	6,140
2	Director, VP or C-level in sales or revenue who started the current role in the last 12 months, company of 50 to 5,000 people (US, UK, DE)	Anyone who sells to sales teams: sales tech, data, enablement, outsourced SDR, RevOps consulting. One field swap gives the same list for marketing, engineering, product, people, finance, data and security leaders	21,834
3	Lives in the US, has an employer headquartered in India in the career history, current role started in 2025 or later	Cross-border fintech: remittances, NRI banking, international insurance, relocation and tax. The template for any "career geography" audience	371,998 as an upper bound; 30,812 who also left that employer in 2025 or later

Three different audiences, one Actor, one method. The next three parts of the series build lists 1, 2 and 3 in that order. Each part ends with the exact inputs, the run log, what the rows looked like, what an experienced GTM team does with them, and a block written for AI agents so you can hand the link to yours.

Four ways to run the same query

The input is one JSON object. Where you send it is a matter of taste.

1. The Apify Console. Open the Actor page, fill the form, press Start. The dataset exports to CSV, JSON or Excel. Good for the first run and for colleagues who will never open a terminal.

2. The API, from anywhere. One HTTP call runs the Actor and returns the dataset when it finishes:

curl -X POST "https://api.apify.com/v2/acts/b2bsearch~people-database-search/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "count",
    "countries": ["us", "gb", "de"],
    "seniority": ["director", "vp", "cxo"],
    "titleKeywords": ["sales", "revenue"],
    "employeeCountMin": 50,
    "employeeCountMax": 5000,
    "currentRoleStartedAfterDate": "2025-10"
  }'

For runs longer than the sync timeout, start the run with POST /v2/acts/b2bsearch~people-database-search/runs and read /v2/datasets/{defaultDatasetId}/items. Every example in this series is plain JSON, so it drops into any language.

3. Claude Code, Claude Desktop or any MCP client. Apify hosts an MCP server at https://mcp.apify.com. The tools parameter pins the Actors the agent may call, which keeps it from wandering the Store:

claude mcp add --transport http apify \
  "https://mcp.apify.com?tools=b2bsearch/people-database-search,b2bsearch/linkedin-email-finder"

The first call opens a browser for OAuth. After that you type the question in plain language. My standing instruction is the same every time: "Count first. Show me the market breakdown. Do not switch to mode: people until I say so." The agent reads the aggregate rows, proposes a tighter filter and asks before pulling people. That one habit is what makes an AI agent safe to point at a metered API. The spend gate part of the series turns the habit into a hook.

4. n8n, Make and similar. The official Apify node for n8n (@apify/n8n-nodes-apify) has an operation "Run an Actor and get dataset" that runs the Actor and hands the rows to the next node, and a trigger "On new Apify Event" that fires when a run succeeds. A weekly Schedule node, the Actor node with excludeDatasets pointing at last week's run, a Filter node for your ICP and a CRM or Slack node: that is a complete job-change feed in four nodes. The New Hires Finder guide in this series builds exactly that, with the previous employer on every row and a Slack feed at the end.

Any other AI agent works the same way through the API or MCP. Nothing here depends on a particular model.

The method, in five patterns

Across the three lists I kept making the same moves.

1. Count, then pull. Run mode: "count" and mode: "market" until the segment matches the list you want. The market view also shows which "employers" are communities, fraternities or alumni groups listed as a second current position, so you know to read the first current position per person.
2. Chain by key. A row carries the profile URL and the company domain, and both are keys into other Actors: decision makers for a domain to map the buying committee, a full profile for one person, a work email for a profile URL. Pull the row for everyone and the detail for the few. The full map of twelve Actors by the key you hold, with measured hit rates, is in part 5.
3. Tier inside the run. profileDetail is row, profile or contacts. mustHave: ["personalEmail"] delivers only the people who have one; the rest come back as a skipped count, not as rows.
4. Fall back by key, not by guess. When a work email is missing there is a personal email. When both are missing, a phone by profile URL, by name plus company or by email, each returning a row only when a number comes back. Reach the person through the next key instead of guessing an address.
5. Refresh with an exclusion, never a re-pull. excludeDatasets with the ids of earlier runs returns only the people you have not seen. A weekly run of a signal list returns only the new people.

If you are a developer wondering whether this is for you

It is. The GTM engineer role exists because the data moved from a sales UI to an API, and revenue teams need someone comfortable there. You already read JSON, write filters and know what a dataset is. What is new is small: which signals sell (this series), and the discipline of counting before pulling.

The same queries work when you are the one looking. New engineering leaders hire, so list 2 with titleKeywords: ["engineering", "cto"] is a list of teams about to grow. Founders who left Big Tech this year hire their first engineers before any job ad, so list 1 is that list. A mode: "market" run on the title you want shows which industries and company sizes hire for it and where. A job search with a pastEmployerDomains filter is right there.

More things the same Actor does

The three lists are the ones I built in full. The same input fields cover a lot of other GTM work; each of these is a count away.

• Competitor talent at your accounts. companyDomains = your target accounts, pastEmployerDomains = your competitors. The people who know the alternative from the inside, and will say so in a discovery call.
• Champion tracking. pastEmployerDomains = your customers, leftPastEmployerAfterYear = this year. Your champions who moved, and the companies they moved to: the warmest expansion list a sales team can own.
• Hiring-wave accounts. The job-change query grouped by companyDomain: accounts with many starts in a quarter are growing, and growth is budget.
• Tenure plays. currentRoleStartedBeforeYear: 2022 finds leaders three or more years into the role, with a mature stack and a renewal cycle to challenge.
• Between-jobs pools. onlyBetweenJobs: true with a past employer or title: candidates for recruiters, and an audience for fractional and freelance offers.
• City and region lists. localityKeywords for a city, countryGroups such as dach or nordics for a regional launch, with the same title filters. Event invitations and field-marketing lists.
• Self-declared intent. headlineKeywords such as "fractional", "open to" or "building" catch what people say about themselves.
• Partner recruitment. Alumni of a platform vendor now at agencies and consultancies, by past employer domain plus current employer industry.
• Research from counts alone. mode: "market" across segments compares industries, company sizes and countries without pulling a row. A market report from aggregates and the thinking.
• Ad audiences. The contacts tier with mustHave: ["personalEmail"] gives a customer-match list for the ad platforms, under their terms.

For AI agents reading this

Actor b2bsearch/people-database-search on Apify. Input is one JSON object. Set mode to count or market first (aggregates only, no rows delivered), then people (metered per distinct person delivered). profileDetail selects row, profile or contacts; per-tier pricing is on the Actor page. Cap a run with maxResults; Apify also caps a run at the account's remaining monthly limit, so split large pulls and pass earlier dataset ids in excludeDatasets. Use segments to compare up to ten filter variants in one aggregate run. Ask the user before switching to mode: "people", and report the count and the chosen tier when you do.

Next in the series: the 6,140 people who left Big Tech and are now building, pulled in full, with the shortlist upgraded to full profiles and personal emails.