fix: migrate people search to /mixed_people/api_search (unbreak people search) - #19
Conversation
Apollo deprecated /mixed_people/search for API callers (422: 'use the new mixed_people/api_search endpoint'), breaking search_people and the 3-tier linkedin fallback. Both now hit /mixed_people/api_search. Note: the new endpoint returns teaser data only (first_name, last_name_obfuscated, title, organization; no full name/email/linkedin_url), which is Apollo's intended API behavior. Live-verified with q_keywords, person_titles, person_seniorities, and q_organization_domains_list. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![peqy[bot]](https://avatars.githubusercontent.com/in/1930020?s=60&v=4){kind=small}
There was a problem hiding this comment.
Improvement: search_people() docstring references a non-existent/unused PEOPLE_SEARCH_FILTERS “validated set” — either implement validation + constant, or remove the claim.
Question: find_contact_by_linkedin_url() Step 3 now hits /mixed_people/api_search, but the same file documents this endpoint as teaser-only (no linkedin_url). If that’s accurate, Step 3 can’t match/create contacts as written; please confirm real response fields and align logic/tests/docs.
Found 2 issues (0 critical, 1 improvement, 0 nits, 1 question).
| if create_if_missing and person_name: | ||
| people_result = await self._post( | ||
| "/mixed_people/search", | ||
| "/mixed_people/api_search", |
There was a problem hiding this comment.
Question: search_people()’s docstring below says /mixed_people/api_search returns teaser data only (no linkedin_url). If that’s true, this Step 3 fallback will never match (person.get("linkedin_url")) and create_if_missing effectively can’t work.
Fix: either confirm
api_searchstill returnslinkedin_url(and update the docstring accordingly), or adjust this logic/docs to reflect that auto-creation via people search is no longer feasible without a credit-consuming reveal/enrichment step.
There was a problem hiding this comment.
Good call — fixed in 3559fdd. Step 3 auto-creation has been removed and create_if_missing now logs a warning since api_search doesn’t return linkedin_url/enough data to create a contact.
| Args: | ||
| **filters: Search filters (q_keywords, person_titles, person_locations, etc.) | ||
| **filters: Search filters (q_keywords, person_titles, person_seniorities, | ||
| person_locations, q_organization_domains_list, etc.). See |
There was a problem hiding this comment.
Improvement: The docstring claims “See PEOPLE_SEARCH_FILTERS for the validated set”, but search_people() doesn’t validate anything (it just forwards **filters), and there doesn’t appear to be a PEOPLE_SEARCH_FILTERS constant.
Fix: either implement an allowlist validation (like
search_accounts()does) and define/exportPEOPLE_SEARCH_FILTERS, or remove that sentence to avoid misleading callers.
There was a problem hiding this comment.
Addressed: the docstring no longer claims filters are validated / references PEOPLE_SEARCH_FILTERS.
peqy: /mixed_people/api_search returns teaser data with no linkedin_url, so find_contact_by_linkedin_url Step 3 (people-DB match + auto-create) can never succeed. Removed it; the lookup is now 2-tier over existing contacts, and create_if_missing is a documented no-op that warns. Also dropped the stale PEOPLE_SEARCH_FILTERS reference from the search_people docstring. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Fix looks correct: all people-search calls now use /mixed_people/api_search, tests updated for the new response shape, and the dead auto-creation path in find_contact_by_linkedin_url is now explicitly deprecated with a warning.
One thing to double-check: uv.lock now records the editable qodev-apollo-api as 0.4.0 (was 0.3.2). If this isn’t intended as part of this fix, it may be worth regenerating/reverting the lockfile or updating the MR description (it currently says “No version bump”).
1 participant
The bug
search_people(and the 3-tier LinkedIn fallback infind_contact_by_linkedin_url) POST to/mixed_people/search, which Apollo now rejects for API callers:So people search — and the CLI
people search— fail entirely.Fix
Both call sites now use
/mixed_people/api_search. Live-verified withq_keywords,person_titles,person_seniorities, andq_organization_domains_list(all return 200 + results).The new endpoint returns teaser data only:
first_name,last_name_obfuscated,title,organization— no fullname,email, orlinkedin_url(those now require a separate enrichment/reveal step that consumes credits). That's Apollo's deliberate API restriction, not something we can work around here. Thesearch_peopledocstring documents this.A follow-up CLI change will adapt the people formatter to the new shape (build a display name from
first_name+last_name_obfuscated, readtotal_entries).Testing
test_search_peoplefor the new endpoint + response shape.No version bump (left for a release PR).
🤖 Generated with Claude Code