ACTION_ID: get_employees_by_company_using_apollo NAME: Apollo: Find Employees at Company CATEGORY: scrape CREDITS: 1.4 credits per 100 employees Find employees at a target company using Apollo as the data provider. Returns a structured array of employee records with the person's name, LinkedIn URL, current title and headline, social profiles (Twitter / Facebook / GitHub), employment history, department / function / seniority, and location (city / state / country). Capped at the requested headcount. Apollo-flavoured employee finder. For email enrichment downstream, pair with the dedicated email-finder waterfall (person_work_email_waterfall) — don't rely on this action for emails. INDEX: 1. Inputs 2. Outputs 3. How to configure 4. Key notes 5. Where it fits in a workflow 6. When to use 7. When not to use ================================================================================ 1. INPUTS ================================================================================ apollo_api_key (type: boolean, optional) — Apollo API key Whether to use a personal Apollo API key for this run instead of Floqer's Apollo connection. Allowed values: "true" / "false" (default "false"). Set to "true" only if you've connected your own Apollo account on the Floqer Connections page; otherwise leave default. number_of_employees (type: string, optional) — Number of Employees Number of employee records to fetch, sent as a string (e.g. "10"). Minimum 1, maximum 100, default 10. Cost scales per 100 employees found, so set this to the smallest number that meets your needs. company_domain (type: url, required) — Company Domain Comma-separated list of company domains or full website URLs to search. Example: "google.com, facebook.com". Bare domain is the canonical form, but full URLs (e.g. "https://www.google.com/") are accepted — the backend strips the scheme, www. prefix, and any path/query/hash before forwarding to Apollo, so you can pipe a website-typed input directly without a normalisation step. titles_of_the_person (type: string, optional) — Titles of the person Comma-separated list of titles to filter by. Example: "CEO, Founder, VP Engineering". Apollo matches profiles whose title contains any of the supplied terms (OR semantics). keywords (type: string, optional) — Keywords Comma-separated keyword filter. AND semantics — profiles must match ALL keywords. Example: "marketing, manager" returns only people with both "marketing" AND "manager" in their profile, not either / or. Use this when you need stricter narrowing than the title filter alone. locations (type: string, optional) — Locations Comma-separated list of allowed person locations. Example: "california, ireland, chicago". Filters on where the person is based (city / state / country) — not the company HQ. seniorities (type: string, optional) — Seniorities Multi-select filter for seniority. The value sent is a JSON array of one or more level IDs from the allowed list: "owner", "founder", "partner", "c_suite", "vp", "head", "director", "manager", "senior", "entry", "intern". Example value: ["c_suite", "vp", "director"]. ================================================================================ 2. OUTPUTS ================================================================================ no_of_employees (type: number) — No. of Employees Number of employees actually returned (may be less than the requested Number of Employees if filters narrow the pool). list_of_employees (type: structured_array) — List of Employees Array of employees found, with one entry per person. Per-row fields: - first_name (type: string) — First Name First name of the employee. - last_name (type: string) — Last Name Last name of the employee. - person_linkedin_url (type: url) — Person Linkedin URL Employee's LinkedIn profile URL. - person_title (type: string) — Person Title Current job title. - person_headline (type: string) — Person Headline LinkedIn-style headline. - person_twitter_url (type: url) — Person Twitter URL Twitter / X profile URL. - person_facebook_url (type: url) — Person Facebook URL Facebook profile URL. - person_github_url (type: url) — Person Github URL GitHub profile URL. - employement_history (type: raw_array) — Employement History Employment history as nested JSON. - departments (type: raw_array) — Departments Departments the person belongs to. - seniority (type: string) — Seniority Seniority label. - functions (type: raw_array) — Functions Functional roles. - phone_numbers (type: raw_array) — Phone Numbers Phone numbers Apollo has on file (when surfaced). - city (type: string) — City City the person is based in. - state (type: string) — State State / region the person is based in. - country (type: string) — Country Country the person is based in. - company_name (type: string) — Company Name Current company name. - company_domain (type: url) — Company Domain Current company domain. ================================================================================ 3. HOW TO CONFIGURE ================================================================================ Configure Action body: { "inputs": { "apollo_api_key": false, "number_of_employees": "10", "company_domain": "{{input.company_domain}}", "titles_of_the_person": "VP of Engineering, Director of Engineering", "keywords": "engineering, infrastructure", "locations": "california, new york", "seniorities": ["vp", "director"] } } Field-by-field: - company_domain Comma-separated company domains or full website URLs (`google.com, https://www.facebook.com/`). The backend strips scheme/www/path before sending to Apollo. - apollo_api_key false (default) for Floqer's shared Apollo connection. - number_of_employees 1-100, default 10. - titles_of_the_person Comma-separated titles, OR semantics. - keywords Comma-separated keywords, AND semantics. - locations Comma-separated person locations (city / state / country). - seniorities JSON array of level IDs from INPUTS. ================================================================================ 4. KEY NOTES ================================================================================ - Cost: 1.4 credits per 100 employees found. Number of Employees caps at 100 per call. Set the cap to the smallest number that meets your needs — start small, verify the filter quality, then scale up. - Filter strategy: Titles + Seniorities work best together, with Keywords as the strict-narrowing knob. - For a *specific* employee search (you want a narrow set, e.g. "VP of Engineering"), put the specific title plus any function qualifier in Titles (e.g. "VP Engineering, Director of Engineering"), AND set Seniorities to the matching level (e.g. ["vp", "director"]). The two filters compound and tighten the result set. - For *maximum coverage* (you want every senior person in a function), put just the function name in Titles (e.g. "engineering, infrastructure") and set Seniorities to the levels you'll accept (e.g. ["c_suite", "vp", "director"]). This catches title variants ("Director of Engineering", "VP, Engineering", "Head of Engineering") that a specific title-string filter would miss. - Use Keywords when even the title + seniority combo is too loose — Keywords applies AND semantics across all supplied terms, e.g. "marketing, manager" returns only people with both terms in their profile. - Pair with push_data_to_sheet to fan out the structured_array into individual rows on a new sheet for per-employee enrichment (email, phone, LinkedIn) before outreach. If you're using more than one employee finder in parallel (e.g. running this action alongside get_employees_by_company_using_floqer_native or get_employees_by_company_using_sales_navigator on the same company to maximise coverage), merge the per-finder structured arrays into one with merge_employee_finder_structured_array first, then push the combined array to a sheet — that way you get a single deduped / unified row set on the new sheet rather than pushing each finder's output separately and ending up with duplicate rows. ================================================================================ 5. WHERE IT FITS IN A WORKFLOW ================================================================================ Pattern (account list -> per-employee outreach): start with a list of target accounts, find the right people at each, expand into rows on a new sheet, enrich each with a work email, then send to outreach. input (target company list — domain per row) -> get_employees_by_company_using_apollo (returns List of Employees as a structured_array of matched employees) -> push_data_to_sheet (one row per employee on a new sheet, with Person Linkedin URL, name, etc. as inputs) -> person_work_email_waterfall (resolve work email per row) -> outreach. Pattern (account-level signal — count people in a function): use the No. of Employees output as a signal on the account row itself, without expanding to per-employee rows. Useful for "how many engineers does this company have?" or "do they have a head of revenue?". input (target company) -> get_employees_by_company_using_apollo (with Titles / Seniorities set to the function in question, Number of Employees set high enough to count) -> read No. of Employees as a per-account signal (filter / score on it) -> outreach prioritization. Pattern (multi-finder coverage): run multiple employee finders in parallel for maximum coverage, then merge before fanning out. input (target company) -> get_employees_by_company_using_apollo (in parallel) + get_employees_by_company_using_floqer_native (in parallel) + get_employees_by_company_using_sales_navigator (in parallel) -> merge_employee_finder_structured_array (deduplicate and combine the per-finder structured_arrays into one) -> push_data_to_sheet (one row per unique employee) -> person_work_email_waterfall -> outreach. ================================================================================ 6. WHEN TO USE ================================================================================ Use get_employees_by_company_using_apollo when: - You want Apollo's particular per-person depth — multiple social URLs (Twitter, Facebook, GitHub), employment history, headline — that the leaner finders don't return. - You already standardise on Apollo data elsewhere in the workflow and want a consistent provider across enrichment steps. - You want a quick employee-count signal for a function or seniority at a target company — e.g. "how many engineers does this company have?" — filter to the relevant titles / levels and read No. of Employees as the answer (skip the row fan-out). - You're running a multi-finder coverage strategy alongside get_employees_by_company_using_floqer_native and / or get_employees_by_company_using_sales_navigator (see KEY NOTES on merging). ================================================================================ 7. WHEN NOT TO USE ================================================================================ Need a cheaper, Floqer-native employee finder (no Apollo dependency, lower per-employee cost) -> get_employees_by_company_using_floqer_native (https://floqer.com/docs/action-detail/get_employees_by_company_using_floqer_native.txt) You specifically need Sales Navigator-sourced employee data — e.g. you trust Sales Nav's coverage / freshness over Apollo's for your ICP, or you want Sales Nav's view of seniority / function as the source of truth -> get_employees_by_company_using_sales_navigator (https://floqer.com/docs/action-detail/get_employees_by_company_using_sales_navigator.txt) Config is broadly similar to this action, but the data comes from Sales Nav and the cost is significantly higher per employee. Reach for Sales Nav only when the data source itself matters — otherwise this action or get_employees_by_company_using_floqer_native is the cheaper default. You only need ONE specific person's contact info, not a list of employees at a company -> person_enrich_using_apollo (https://floqer.com/docs/action-detail/person_enrich_using_apollo.txt) Use a person-enrich action with name + company instead of pulling the full employee list and filtering. You need a conditional / fallback search — e.g. "look for C-suite titles at this company; if there's no one at C-suite, fall back to VPs; if no VPs, fall back to Directors". This action returns a single filtered list per call and can't branch on whether the first filter found anyone -> llm_web_agents (https://floqer.com/docs/action-detail/llm_web_agents.txt) A web agent can run the conditional logic in one step ("find me the most senior person at this company in [function] — try C-suite first, then VP, then Director") and return whoever it finds. Use that instead of chaining several calls of this action with different filters. ICP is small, fragmented, or under-indexed in standard B2B databases — independent shops, family businesses, government contractors, regional service providers, anything below ~50 headcount in non-tech verticals. Apollo will return "No data found" for many such companies, which errors the action and halts the row's chain -> llm_web_agents with raw_array fan-out (https://floqer.com/docs/action-detail/llm_web_agents.txt sections 5 and 8) Use the web agent to read company websites, Companies House, news, YouTube, and other sources Apollo doesn't index. Apply size-tiered title logic in the prompt, return a raw_array of people, then pipe through raw_to_structured_array -> push_data_to_sheet. Reach for this action when targeting tech companies, mid-market and up, or any segment with dense LinkedIn coverage. ================================================================================ This file is maintained manually. Last updated: 2026-05-07. Full interactive reference: https://floqer.com/docs/reference Action catalog: https://floqer.com/docs/action-catalog.txt