$ man apollo-wiki/seniority-title-filtering
Core Conceptsintermediate
Seniority and Title Filtering
Solving the title leakage problem with allowlist/blocklist patterns
☾
The Title Leakage Problem
You search Apollo for "VP of Marketing" at SaaS companies. You get back 200 results. You start scrolling and find: VP of Marketing Operations, VP of HR who used to be in marketing, a "Marketing" job title that is actually an engineering role at a marketing tech company, an intern with "Marketing" in their LinkedIn headline. Title leakage is the single biggest quality problem in people search. Apollo's seniority filters help, but they are not enough on their own. You need an allowlist/blocklist pattern.
PATTERN
The Allowlist Pattern
Start with Apollo's built-in seniority filter. Set
person_seniorities: ["vp", "director", "c_suite", "founder"] to exclude individual contributors. Then add a title allowlist - specific strings the title MUST contain: "marketing", "growth", "demand gen", "revenue". This narrows the aperture. Finally, add a title blocklist - strings that disqualify: "intern", "assistant", "coordinator", "HR", "human resources", "engineering", "developer", "recruiter". The blocklist catches the leakage that seniority filters miss. Run allowlist first, then blocklist. Order matters.CODE
Implementation in Python
The pattern lives in a simple function. Take the raw Apollo results, iterate through contacts, check
title.lower() against your allowlist (any match = keep), then check against your blocklist (any match = drop). Log the drops so you can tune the lists over time. In production, this function sits between the Apollo API call and the Supabase insert. It is the quality gate. Without it, you are importing garbage into your pipeline and burning enrichment credits on unqualified contacts.PRO TIP
Tuning the Lists
Your allowlist and blocklist are living documents. After every sourcing run, review the drops. If you are dropping too many valid contacts, your blocklist is too aggressive. If garbage is getting through, your allowlist is too broad. The goal is not perfection on the first run - it is a feedback loop that improves over time. Keep the lists in a config file, not hardcoded. A YAML or JSON file that you can edit without touching the sourcing script. That way non-technical team members can tune the lists too.
related entries