Repository navigation
feat: sync with the 2026-10-14 API release - #30
Merged
Merged
Conversation
Request side: top-level `is_recent_hire` on search.people, company.tam_by_people, search.employee_finder, search.waterfall_icp and both company_distribution_by_* methods; `include_active_jobs`/`include_past_jobs` on search.people and search.waterfall_icp; `company.mx.provider` (new generated `MxProvider` enum, 66 values) on search.companies, search.people and company.tam_by_people; and `people.education.start_year`/`end_year` range filters. The distribution methods get their own `CompanyDistributionParams` so the flag stays off enrichment.company, since the API now 422s on unknown fields. Response side: `found` on both distribution responses; country `count` and `total_employees` now count people, not jobs. Docs: `[brackets]` exact match on job.title, company.hq.city/state and cascade titles; the matched past job's `job_is_current`; the 422/503 notes, the Location/HQ superset list and the decision log in docs/CONTEXT.md; a README example. Tests: request-body, model, compile-time (@ts-expect-error) and 422-body coverage.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
The MxProviderFilter comment said exclude: ["any"] keeps companies with no MX data, then said exclude never drops them unless you use "any". The second clause was copied from the runtime spec's mx description, which contradicts its own provider description. Follow the provider text and its worked example, and record the upstream ambiguity in docs/CONTEXT.md.
…e tiers At the API owner's direction, `is_recent_hire`, `include_active_jobs` and `include_past_jobs` now sit inside the `people` object on search.people and inside each `cascade` tier on search.waterfall_icp; company.tam_by_people takes `people.is_recent_hire` only. search.employee_finder and both company_distribution_by_* methods keep a top-level `is_recent_hire`. `PeopleFilter` gains `is_recent_hire`; a new `PeopleSearchFilter` carries the job-history flags so they stay off tam_by_people, and `CascadeTier` carries all three. The mixins are renamed RecentHireFlag / JobHistoryFlags now that they sit in filter objects. The runtime spec still publishes the top-level form, so a request-side diff shows exactly that placement difference until upstream republishes; it is recorded in docs/CONTEXT.md. Compile-time guards flip to reject the old placement, and the request tests annotate their bodies with the params types so excess-property checks apply.
Re-pulled the runtime spec: the flags now published inside `people` and each `cascade`
item, matching the SDK, so the request-side diff is empty again.
New response field `mx` (MX records, `{ priority, host }`, at most 10) on
`enrichment.company` (`Company.mx`) and `enrichment.email` (`mx` and `all_emails[].mx`).
The email one is in the spec but in no changelog entry. `mx` is declared once as
`MxRecords` and is not coerced through `blitzList`: `null` means no MX data and `[]`
means the domain takes no mail, so collapsing them would lose information.
Tests pin that null, [] and absent stay distinct; docs/CONTEXT.md records the exception
to the blitzList rule and the new expected spec-vs-SDK difference (`Company.mx` on search
and TAM results, which share the model).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Syncs the SDK with the 2026-10-14/15 API releases:
is_recent_hire,include_active_jobsandinclude_past_jobssit insidepeopleonsearch.people(is_recent_hireonly oncompany.tam_by_people) and inside eachcascadetier onsearch.waterfall_icp, with a top-levelis_recent_hireonsearch.employee_finderand the two distribution methods, pluscompany.mx.provider(new generated 66-valueMxProviderenum),people.education.start_year/end_year,foundon both distribution responses, and the newmxMX-records field onenrichment.companyandenrichment.email(the latter is in the spec but in no changelog entry).mxis the one list that is not coerced throughblitzList, becausenull(no MX data) and[](domain takes no mail) mean different things; this is an exception to the rule in CLAUDE.md that needs a maintainer decision. Wrong flag placements are compile errors because the API 422s on unknown fields, and docs cover[brackets]exact match, theLocation/HQ/Company.mxexpected-difference list, the MXexcludewording fix and decision-log entries indocs/CONTEXT.md, along with a README example. Tests cover request bodies, models, compile-time placement and the 422 body, and a field-by-field and kind-level diff against the latest live spec is clean apart from those documented differences (checked against the spec and changelog only; no live API calls).
No new blocking code issue was found.Summary
Syncs request filters, generated provider values, and response fields with the October API release.
Reviews (4) · Last reviewed commit: "feat: add the mx response field and sync..." · Reviewed by Greptile