$ 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
Apollo API ArchitecturePeople Search First: Why Apollo Before ClayConference Prospecting with Apollo
← apollo wikiclay wiki →
ShawnOS.ai|theGTMOS.ai|theContentOS.ai