🔗 Linkedin Mass People Profile Finder By Name, Company & City Columns

Type your spreadsheet's own columns — first name, last name, company, job title, city — and get back the LinkedIn URL, the exact question that found it, and every attempt tried.

This is a variant of the base Linkedin Mass People Profile Finder. Everything the base does with the queries box is unchanged — you can still paste free-text search strings exactly as before. This variant adds a second, structured way in: a people list where you fill in the columns you already have (first name, last name, company, job title, city) instead of hand-writing a query string, and the actor builds the search for you. Add a company or a city to a name and you get back different people than the bare name alone would — that's the whole point of typing them separately instead of squashing them into one free-text line.

---

✨ What's different from the base

• 👤 Structured people input — one JSON row per person: firstName, lastName, company, jobTitle, location. The actor assembles the quoted-phrase search query from whichever columns you filled in.
• 🔁 Query ladder — if a person's full-column search comes back empty, the actor automatically re-asks with one detail dropped, then another, down to the bare name, stopping the instant a profile comes back. This only ever runs after a miss, so a clean list costs exactly what it costs today.
• 🪜 Configurable drop order — choose which detail goes first when the ladder loosens the question (default: job title first, then city, employer kept longest).
• 🌍 Search region — switch the search index's regional edition for non-US lists.
• 🧾 Full provenance on every row — query_used (what actually found it), columns_used (which of your columns survived into that query), query_attempts[] (every attempt issued, hit or miss), and person_input (your row, echoed back for joining in a CRM).

The base's queries box and proxyConfiguration are 100% unchanged — same fields, same types, same defaults, same order. An API caller who sends only queries gets exactly the base's behaviour plus the five new provenance columns; no ladder runs, no extra requests.

---

📥 Input

{
  "queries": [
    "\"Michael Dell\" \"Dell Technologies\" CEO"
  ],
  "people": [
    { "firstName": "Michael", "lastName": "Dell", "company": "Herbert Smith Freehills", "jobTitle": "Partner", "location": "New York" },
    { "firstName": "Sarah",   "lastName": "Chen",  "company": "Stripe",                  "jobTitle": "",       "location": "San Francisco" }
  ],
  "queryLadder": true,
  "ladderOrder": ["jobTitle", "location", "company"],
  "searchRegion": "us-en",
  "proxyConfiguration": { "useApifyProxy": false }
}

Field	Type	Description
queries	array<string>	Required (base field, unchanged). Free-text search queries, one per item.
proxyConfiguration	object	Base field, unchanged. Proxy override; default: no proxy, auto-escalates on block.
people	array<object>	New. One row per person: firstName, lastName, company, jobTitle, location — all optional strings. Leave [] to use queries only.
queryLadder	boolean	New. Default true. Re-search with fewer columns on a miss, down to the bare name.
ladderOrder	array<string>	New. Default ["jobTitle","location","company"]. Which detail is dropped first, second, third.
searchRegion	string	New. Default "us-en" — identical to the base's hardcoded value, so leaving it alone changes nothing.

---

📤 Output

Base fields (linkedin, input, error) are unchanged — same meaning, same conditional presence for error (only on a miss). Five fields are appended to every row:

{
  "linkedin": "https://www.linkedin.com/in/michael-dell-508a8711",
  "input": "\"Michael Dell\" \"Herbert Smith Freehills\" \"Partner\"",
  "query_used": "site:linkedin.com/in \"Michael Dell\" \"Herbert Smith Freehills\" \"Partner\"",
  "columns_used": ["firstName", "lastName", "company", "jobTitle"],
  "query_attempts": [
    { "step": 1, "query": "site:linkedin.com/in \"Michael Dell\" \"Herbert Smith Freehills\" \"Partner\" \"New York\"", "results_returned": 0, "linkedin": null },
    { "step": 2, "query": "site:linkedin.com/in \"Michael Dell\" \"Herbert Smith Freehills\" \"Partner\"", "results_returned": 2, "linkedin": "https://www.linkedin.com/in/michael-dell-508a8711" }
  ],
  "person_input": { "firstName": "Michael", "lastName": "Dell", "company": "Herbert Smith Freehills", "jobTitle": "Partner", "location": "New York" },
  "search_region": "us-en"
}

+ Field	Type	What it is
query_used	string | null	The literal query string that returned a profile, prefix included. null on a total miss.
columns_used	array<string>	Which of this row's people keys were still in query_used. [] for a queries-box row. A record of what was asked — never a strength, never a score.
query_attempts	array<object>	One entry per attempt actually issued: {step, query, results_returned, linkedin}.
person_input	object | null	The people entry for this row, echoed back so you can join on your own columns. null for a queries-box row.
search_region	string	The region value actually passed to the search call.

---

⚠️ Honest limits

• Nothing here confirms identity. The output says which question was asked and what came back. Whether the profile is the person you meant is a judgement only you can make — the words "verified", "matched" and "confirmed" describe nothing this actor does.
• A tighter question drags in wrong-name people, not fewer wrong answers. Adding a company or a city changes which people come back, not whether they're the right one. That's exactly why this variant hands you query_used and columns_used instead of a made-up confidence score.
• queries is still required. Its own 2-line prefill still produces 2 extra rows on a bare run unless you clear it — a base wart this variant cannot remove without breaking compatibility.
• This never opens a LinkedIn profile. Every result comes from a search engine's index of public linkedin.com/in pages, so a result can be out of date, renamed or deleted.
• The ladder only ever runs after a genuine miss, and even then only on people rows — a queries row behaves exactly as it does in the base today, Bing fallback included.
• The ladder never falls back to Bing. Bing's fallback measurably returns a full page of results and zero LinkedIn profiles — because it's an HTTP 200 the actor can't tell it failed, so a ladder miss stays a miss rather than silently trying a second engine.
• Only us-en is the well-trodden path. The other region codes are documented ddgs region codes; results outside us-en are less exercised.
• Nothing is computed. No score, no ranking, no comparison to a previous run, no stored history.

---

🤖 Use via API

curl -X POST \
  "https://api.apify.com/v2/acts/<ACTOR_ID>/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "queries": ["\"Michael Dell\" \"Dell Technologies\" CEO"],
    "people": [
      {"firstName": "Michael", "lastName": "Dell", "company": "Herbert Smith Freehills", "jobTitle": "Partner", "location": "New York"}
    ],
    "queryLadder": true
  }'

---

💬 Support

Issues or feature requests? Contact us at dev.scraperengine@gmail.com (same address as the base).