- Brand
- Canonical
- Category
- Sales & CRM
- Primary Subcategory
- B2B Prospecting & Contact Data
Integration details
Description
Canonical is verified company search for research and prospecting. - Describe companies in plain language, or use structured filters like location, headcount, funding stage, investor, and founder background. - Get a precise, LLM-verified, domain-keyed shortlist of real companies instead of a page of links. - Search for companies that match specific criteria. - Find look-alike companies based on a company you already know. - Pull full company profiles, including founders and where they worked before. - Resolve a company name to its correct domain. - Check your Canonical credit balance. - Useful for sales prospecting, market research, competitor research, investor mapping, and sourcing. - Free to start, no credit card required.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- B2B Prospecting & Contact Data
- Secondary Subcategories
- None listed
- Brand
- Canonical
- Access
- Account required
- First tracked
- 2026-07-13
- Tool count
- 7
- Market
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Your score is coming
ChatGPT now suggests Plugins on its own when they match a user's request.Your Plugin Discovery Score measures how often yours appears, and it will show here as soon as it’s ready.
What discovery looks like

Get alerts for Canonical Company Search
Get updates when Canonical Company Search’s Discoverability Score or category rank changes.
Competing in ChatGPT B2B Prospecting & Contact Data
View Category7 tools agents can invoke
Find people — founders and executives — at companies, or a company's leadership. Covers company founders, executives and other business leaders in their professional roles; returns no email addresses, phone numbers or home addresses. Scope it one of three ways: - `company_domains`: the leadership of up to 25 known companies (e.g. domains from a previous search). Up to 10 people per company. - `description` and/or company filters (`cities`, `countries`, `employee_count_min`, `funding_series`, ...): people at companies that match, exactly as `search_companies` matches companies. - `previously_at` alone: people who used to work at those companies and now hold a role elsewhere; add company filters to narrow where they are now. Person conditions — combine freely; all must hold for the same person: - `roles`: when omitted, returns decision-makers (founders, C-suite, and VPs / heads / directors / owners / partners / presidents). - `title_contains`: any of these terms in the person's current title. - `person_location`: where the PERSON is based ("London"). Use `cities` / `countries` for where the company is headquartered. - `previously_at` + `previous_title_contains`: a prior employer (name or domain) and the title held THERE. Internships don't count. Each term matches whole words; a term of five or more letters also matches words that start with it ("engineer" matches "Engineering"). Each person: `name`, `role`, `title`, `company` {`name`, `domain`}, `location`, `linkedin_url`, `prior_companies` (up to 3), `confidence` ("high" | "medium"), `last_verified` (date). Pass `company.domain` to get_company_details for the full company profile. `warnings` lists companies that couldn't be resolved; an ambiguous name lists candidate domains — ask the user which one, or retry with a domain. When `next_cursor` is present there are more people: call again with the same arguments plus `cursor` for the next page (pages stay available for 24 hours). `company_domains` returns everything in one call. Costs 1 credit per person returned; with `company_domains`, 1 credit per company that returned people. Nothing found is free. The response includes `credits_used` and `credits_remaining`. Args: description: What the companies do, as in search_companies. cities: Company HQ cities. states: Company HQ states / regions. countries: Company HQ countries. employee_count_min: Minimum company headcount. employee_count_max: Maximum company headcount. founding_year_min: Earliest company founding year. founding_year_max: Latest company founding year. is_public: true for listed companies only. funding_series: Latest funding round, as in search_companies. funded_after: Latest round on or after this date (YYYY-MM-DD). funded_before: Latest round on or before this date (YYYY-MM-DD). funding_investor: Companies backed by these investors. company_domains: Leadership mode — up to 25 company domains. roles: "founder", "cofounder", "ceo", "cto", "cfo", "coo", "chief_other", "exec_other". title_contains: Any of these terms in the current title, e.g. ["growth"]. person_location: Where the person is based, e.g. "Berlin". previously_at: Prior employers (names or domains), up to 10. Internships don't count. previous_title_contains: Any of these terms in the title held at the prior employer, e.g. ["cto", "chief technology"]. top_k: People per page, 1-100 (default 25). cursor: `next_cursor` from the previous page.
find_people
Find companies similar to a given company by domain. Args: company_domain: Domain of the seed company (e.g. "stripe.com"). Required for a new search; omit only when resuming a previous search via `cursor` (the seed is pinned server-side from the original call). top_k: Number of similar companies to return (1-1000, default 25). Use 25+ for a broad set of look-alikes, and fewer when the user wants just the closest one or two. Each returned strong match costs 1 credit, so match `top_k` to what the user asked for. intent: Optional ranking profile that reorders the similar set AFTER similarity filtering — same taxonomy and selection rule as `search_companies` (pick the slug matching the user's use case; omit / pass null for relevance-only ordering). Intent only changes the ORDER of the matched set; it never changes which companies are in it, the candidate pool, or the credits charged. Use it for requests like "companies similar to Stripe that are hiring/growing fast" or "...ranked for who's buying now". Allowed slugs: - "sales_prospecting": general outbound ICP list. - "sales_timing": accounts with a near-term buying window. - "sales_expansion": existing customers ripe for upsell. - "competitive_tracking": monitor NAMED competitors' direction. - "emerging_competitor_scan": discover rising new entrants. - "talent_source": companies to poach candidates from. - "recruiter_employer_vet": vet a company for a candidate. - "jobseeker_stability": job security over upside. - "jobseeker_growth": career-growth / high-momentum companies. See `search_companies` for the full per-slug guidance. include_partials: When True, also returns LLM-evaluated "partial" matches (close but not strong). Off by default because partials aren't billed; opt in only when the user wants exploratory context beyond strong matches. Default False. exclude_company_domains: Optional list of company domains to exclude from the similar-companies results. Useful when the seed has obvious near-clones you want to skip (e.g. "similar to Stripe, not Square or Adyen"). Unresolvable domains appear in `warnings`. cursor: Opaque pagination token from a previous response's `next_cursor`. Pass it back (with `company_domain` omitted) to fetch the next page of the SAME similar-companies search — the original seed company is pinned from the first call. The response includes `next_cursor` when more results remain; pass it back as `cursor` to page through the rest without re-querying from scratch. When presenting results to the user, render each company's `domain` as a clickable link to the company's website (e.g. as a Markdown link to https://<domain>). Note: each candidate is independently LLM-verified, so the exact set (and therefore the result count and credits charged) can vary slightly between otherwise-identical calls — borderline matches may pass on one run and not the next. This is expected and is not affected by `intent`.
find_similar_companies
Return the authenticated org's credit balance, plan, and search rate limits. Use this to check remaining credits before issuing a search, or to pace requests against the org's per-minute and per-day limits. This call is completely free — it charges no credits and does not count against the search rate budget. Returns: - `credits`: bucket breakdown (`total`, `subscription`, `extra`) and `subscription_resets_at` (ISO datetime string or null) — when the subscription bucket will next be refilled. - `plan`: the org's current plan name (e.g. "free", "lite", "starter", "pro"). - `rate_limits`: `per_minute` and `per_day` search operation limits for the current plan.
get_account_status
Return the full detail payload for one canonical company by domain. Use this AFTER a search to drill into a specific company. Returns: - `company`: full canonical fields (name, domain, description, hq, employees, funding, dimensions). Includes `defunct` (bool) — when true the company has shut down, so don't route users to it — and `is_public` (bool) — true when the company is publicly listed; false means private or unknown. Always present when the domain resolves to a known company. Internal `id` fields are intentionally not included. - `company.hiring`: what the company is currently hiring for, from a weekly scrape of its job board — `active_job_count` (total open postings), `has_remote_job`, and three breakdowns each carrying `[{name, count}]` ranked by posting count: `by_department` (up to 15), `by_country` (up to 10, already country NAMES, not codes) and `by_city` (up to 5). Quote the counts, not just the labels: "412 engineering roles" is the answer; "hiring engineers" throws the number away. ABSENT when we hold no posting data for the company, which is not the same as the company not hiring — coverage is roughly 20,000 companies. Never report a missing block as "this company is not hiring"; report it as "no hiring data". The breakdowns are ranked top-Ns for reading, not the complete sets — a company hiring in 3,371 cities shows five — so to FILTER on hiring use `search_companies`' job_* parameters, which match against the full lists. - `people`: key people (cofounders + C-suite/execs — not only founders) with role, headline, LinkedIn URL, and `prior_companies` (each with category tags like 'faang', 'unicorn', 'top_startup', 'big_tech', 'mbb', and a `domain` handle you can pass back into this tool to walk the company graph). May be empty. - `leadership_data`: `"available"` (people populated), `"not_available"` (company is in our DB but not in the leadership subset — most companies fall here), or `"error"` (transient lookup failure). - `relationships` (present only when the company has corporate- relationship edges; `source` reports their provenance, e.g. 'analyst_curated'): `parents` (direct owners, each with a `relation` like 'wholly_owned_subsidiary'), `ultimate_parent` and `lineage` (ownership chain ordered root→immediate parent; null/empty when the company is top-level or ownership is ambiguous, e.g. a joint venture with multiple owners), and `children` (ALL related companies, grouped by category — subsidiary, product_of, joint_venture, merger, other — ordered largest-first; lists are complete, never truncated). Every related company carries a `domain` — pass it back into this tool to walk the corporate graph (each hop costs 1 credit). A subdomain resolves through its registered domain when only the parent is a known company: `coilcoatings.akzonobel.com` returns AkzoNobel. When that happens the response carries `requested_domain`, `matched_domain` and `resolved_via: "registered_domain"` — the profile is then the PARENT company's, so attribute its headcount, funding and hiring to the parent, say which company you are reporting on, and check `relationships.children` for the specific unit that was asked about. These three keys are ABSENT when the requested domain resolved exactly, which is the normal case. Costs 1 credit per call, charged only when the domain resolves to a real company (a not-found domain is free). Response includes `credits_used` and `credits_remaining`. Rate-limited to prevent enumeration. When showing this to the user, render the `domain` as a clickable link to the company's website (e.g. as a Markdown link to https://<domain>). Args: company_domain: Domain of the company (e.g. "stripe.com") — the same handle returned in search results.
get_company_details
Look up companies by name to disambiguate before another tool. Use this when a user names a company you'll feed into `find_similar_companies` (as a seed) or `search_companies` (as an `exclude_company_domains` entry) and the name might be ambiguous. Returns, per input name: - `candidates`: ranked (best-guess-first) list, each with `name`, `domain`, `headquarters`, `description`, `is_primary`, `match`, and `payload_richness`. `match` is `"exact"` when the candidate's name IS the name asked for (punctuation folded, a leading article allowed to differ) and `"partial"` for a prefix, infix, or fuzzy hit — use it to tell a real name match from a lookalike when confidence is `"low"`. - `confidence`: `"high"` (one entity) | `"medium"` (a dominant entity among rivals) | `"low"` (comparable rivals — a real toss-up). - `primary_candidate_domain`: the recommended domain, or `null` when asking. - `auto_resolve_recommended`: bool. Batch size — at most 10 names per call. For a longer list, split it and send the calls ONE AFTER ANOTHER, not in parallel: parallel batches queue on the same database and each gets slower. Input shaping — RAISES HIT RATE: a trailing legal form (GmbH, SE, S.A., S.p.A., B.V., Inc, Ltd, LLC, s.r.o., d.o.o., …) is stripped for you, so send `"Arvato SE"` as-is; do NOT also send `"Arvato"`, which only uses up the 10-name limit. What is NOT stripped for you, and so is worth a second entry: a **leading article** (`["The Home Depot", "Home Depot"]`, `["The Kroger Co", "Kroger"]` — the corpus stores some companies under the article and some without it), a location qualifier (`"Raima Barcelona"` → add `"Raima"`), and a multi-word holding form (`"CEQUENS HOLDING LIMITED"` → add `"Cequens"`). If a domain is embedded in the name, pass it as its own entry (`"Undo (undo.io)"` → add `"undo.io"`). For a non-Latin name, add a transliteration or English trade name if known. Send the extra forms alongside the original, never instead of it. Disambiguation policy — FOLLOW THIS: - If `auto_resolve_recommended` is true, proceed silently with `primary_candidate_domain` (the one candidate marked `is_primary`). Do NOT ask the user — the match is unambiguous (one entity, or a clear dominant one). - If `auto_resolve_recommended` is false, `primary_candidate_domain` is `null` and NO candidate is `is_primary` — none is authoritative. Present `candidates` to the user as a list and WAIT for them to pick before calling the next tool. Do not auto-select even if one looks right — disambiguation is the point. Costs 1 credit per call, charged only when at least one candidate is returned (a no-match lookup is free) — regardless of how many names or candidates. Response includes `credits_used` and `credits_remaining`. Rate-limited. Args: names: 1-10 free-text company names to look up. Split longer lists across sequential calls. k: How many candidates to return per name (1-25, default 5). disambiguation_mode: Override the recommendation for non-interactive callers. "auto_when_confident" (default) follows the policy above; "always_auto" never asks (use the primary); "always_ask" always asks.
lookup_companies
Find specific people by name — their current role and company. Covers company founders, executives and other business leaders in their professional roles; returns no email addresses, phone numbers or home addresses. Pass up to 10 `people`, each `{name, company}`. `company` is optional but strongly improves the match: a domain ("stripe.com") or a company name. Returns the best matches per name (up to `k`), each with `matched_name` (the name you passed) plus the same fields as find_people. Several matches for one name are different people who share it: show their companies and ask which one. Names with no match are listed in `unmatched`. A name found only at companies other than the `company` you gave is listed in `unconfirmed`, without those people; look it up without `company` to see them. Returned matches that are not at that company are flagged `company_match: false`. Costs 1 credit per name that matched at least one person; unmatched and unconfirmed names are free. The response includes `credits_used` and `credits_remaining`. Args: people: Up to 10 entries of {"name": ..., "company": ... (optional)}. k: Matches to return per name, 1-5 (default 3).
lookup_people
Search Canonical's company database by a description of what a company does, plus exact filters. Filters cover location, headcount, funding, founding year and hiring. Each candidate is checked by an LLM verifier against the description. `description` is the only fuzzy / semantic field: it expresses a free-text concept (e.g. "enterprise SaaS for supply-chain visibility"), which is passed to an LLM verifier that checks each candidate against the intent and returns a verdict. Everything else is an exact, hard filter — the pipeline enforces it before the verifier sees a result. IMPORTANT — unsupported constraints: there is intentionally NO field for constraints we cannot enforce (founder demographics, profitability, YC / accelerator batch, individual revenue figures). ALWAYS tell the user it isn't a supported filter — never present a result as though it was applied. What you do next depends on the KIND of constraint: - A QUALITATIVE property a factsheet could describe ("YC S22 company", "developer-first", "agency rather than product") → it may go in `description` for loose semantic verification: "YC S22 company" → description="Y Combinator Summer 2022 batch startup". Say that you matched it loosely rather than filtered on it. - A NUMBER we do not hold (revenue, ARR, turnover, profit, margin, the valuation of a private company) → it must NOT go in `description`. There is no revenue, ARR or turnover figure anywhere in the factsheet, so the phrase filters nothing: it only changes which companies look similar, and the search still charges for every company it returns. Substitute the nearest thing we DO hold — for company size that is `employee_count_min` / `employee_count_max` — and say you substituted headcount for the figure they asked for. Asking for "$2M+ revenue" and getting a headcount floor is a good answer; getting an unfiltered page presented as a filtered one is not. IMPORTANT — exclusions belong in `exclude_description`, never in `description`. When the user says a company should NOT be something ("no drinks-only co-packers", "exclude logistics and distributors", "not consulting"), put that concept in `exclude_description`. A negation written into `description` is read as POSITIVE signal — it pulls in the very companies you meant to exclude and sharply lowers precision. IMPORTANT — `description` is matched against a company factsheet, and the verifier scores only three things: what the company OFFERS, WHO it serves, and HOW it makes money. That last one is the BUSINESS MODEL — how it charges (subscription, marketplace take-rate, licensing, ads) — and not how much it earns: the factsheet carries no revenue, ARR or turnover figure at all. Route every other constraint to its own field, or it silently retrieves the wrong companies: - Size ("large", "major", "enterprise-scale") → `employee_count_min` / `employee_count_max`. There is no size axis in the verdict, so a size word left in `description` filters nothing at all. - Location → `countries` / `states` / `cities`. Don't also name the country in `description`. - Funding ("well funded", "raised over $10M", "Series B", "backed by Sequoia") → `funding_series` / `funding_min_usd` / `funding_max_usd` / `funded_after` / `funded_before` / `funding_investor`. Same silent no-op as size: money raised is a number the verdict never looks at. A named period ("in 2024", "in Q1 2025") needs BOTH date bounds — one bound is an open-ended "or later", which is a different question. - Age ("early-stage", "founded after 2020", "recently started") → `founding_year_min` / `founding_year_max`. - Listing status ("public", "publicly traded", "listed", "private", "privately held", "pre-IPO") → `is_public`. The verifier has no ownership axis, so the word filters nothing in `description`. Funding words ("VC-backed", "Series B") say nothing about listing status — a listed company has a funding history too — so they never set it. - Why you want the list ("sources of talent", "benchmarks for X", "acquisition targets") → `intent`. Never restate it in `description`. - A factsheet describes what a company SELLS. So any phrase naming what a company BUYS, USES, EMPLOYS or IS SUBJECT TO retrieves the companies that SELL that thing, not the ones you meant. Describe the target by what IT does, and put the thing-it-uses in `exclude_description`. (Ask for employers that offer a benefit and you get the benefit's vendors; ask for companies to recruit from and you get recruiters.) Args: description: Free-text semantic concept describing what the company does. This is the ONLY fuzzy field — the LLM verifier reads it and checks each candidate for match/partial/irrelevant. Examples: "B2B SaaS for HR teams", "consumer fintech targeting millennials", "climate tech in renewable energy storage". Omit (or pass null) for purely filter-driven searches (e.g. "all Series B companies in India with 50-100 employees"). Describe ONLY what the company SHOULD be. Do NOT embed exclusions or negations here (no "exclude X", "not Y", "without Z", "excluding …") — those belong in `exclude_description`; left here they are treated as positive signal and hurt results. cities: Restrict to companies headquartered in these cities. Exact match (case-insensitive). Example: ["San Francisco", "New York"]. For a metro/region, list all constituent cities and include common name variants (e.g. Gurgaon/Gurugram, Bengaluru/Bangalore). states: Restrict to these states/provinces. Example: ["California", "New York"]. Use full name, not abbreviation. countries: Restrict to these countries. Expand geographic regions to their constituent countries before passing — e.g. "Southeast Asia" → ["Indonesia", "Vietnam", "Thailand", "Philippines", "Malaysia", "Singapore"]; "Nordics" → ["Sweden", "Norway", "Denmark", "Finland", "Iceland"]. Single country: ["India"]. Only set this when the user EXPLICITLY names a geography. Do NOT infer a country from the user's own locale, timezone, or language — an unrequested location filter silently drops the large majority of matches (companies are worldwide). When in doubt, leave it unset. employee_count_min: Smallest company headcount to include (inclusive). E.g. employee_count_min=5 with employee_count_max=25 means "5-25 employees"; min alone (e.g. 500) means "500+". For "well-funded startup" signals, use funding_min_usd instead. employee_count_max: Largest company headcount to include (inclusive). Omit for an open-ended upper bound. founding_year_min: Lowest founding year to include (inclusive 4-digit year). E.g. 2015 means "founded in 2015 or later". Combine with founding_year_max to express a range. founding_year_max: Highest founding year to include (inclusive). E.g. 2020 means "founded in 2020 or earlier". For an exact year, set founding_year_min == founding_year_max. founding_year_exclude_min: Lowest year of a contiguous range to EXCLUDE (inclusive). Both exclude_min and exclude_max must be set together; for a single-year exclusion ("not founded in 2020"), set both to the same year. founding_year_exclude_max: Highest year of the contiguous range to EXCLUDE (inclusive). Note on NULLs: companies with unknown founding year are DROPPED when including (min/max), but KEPT when excluding — matching the intuitive reading of "not founded in 2020" (unknowns might be). is_public: True → only publicly listed companies (stock-exchange traded). False → private OR unknown listing status; we hold listing data for a minority of companies, so False alone is coarse — combine it with other criteria. Omit for no filter. funding_series: One or more funding-round labels to include. Values: "pre_seed", "seed", "series_a", "series_b", "series_c", "series_d", "series_e", "series_f", "series_g_plus", "growth", "late", "bridge", "venture", "angel", "other". funding_min_usd: Minimum LATEST-ROUND funding amount (USD). Heuristics: "well-funded startup" ≈ 50_000_000; "unicorn-range" use funding_post_money_min_usd instead. funding_max_usd: Maximum LATEST-ROUND funding amount (USD). Pair with funding_min_usd for a two-sided range (e.g. "raised between $10M and $20M"); omit for an open-ended upper bound. funding_post_money_min_usd: Minimum post-money valuation (USD). Heuristic: "unicorn" ≈ 1_000_000_000. funding_post_money_max_usd: Maximum post-money valuation (USD). Pair with funding_post_money_min_usd for a two-sided valuation range; omit for an open-ended upper bound. funded_after: Only include companies whose most recent round is on or after this ISO date (YYYY-MM-DD). Example: "2022-01-01". funded_before: Only include companies whose most recent round is on or before this ISO date (YYYY-MM-DD) — the "went quiet since" filter. PAIR THE TWO for any bounded period. A named year, quarter or month is a two-sided window and needs both ends: "raised a Series B in 2024" is funded_after="2024-01-01" AND funded_before="2024-12-31", not funded_after alone — that reads as "2024 or later" and returns mostly rounds from after the year asked about. Both bounds describe THE MOST RECENT round, not any round in the company's history. So this finds companies whose latest round is a Series B dated in 2024; a company that raised its Series B in 2024 and a Series C since will NOT match. When the user's wording is about a past round ("raised a Series B in 2024", "Series A in 2021"), say that you matched on the latest round, because the companies that have since raised again are missing from the answer. funding_investor: Filter to companies backed by these investors, matched against the investor names on file. Matching is EXACT — this tool does no alias or fund-family expansion, so "Sequoia" will not match "Sequoia Capital". Pass every spelling you want to hit as its own entry, e.g. ["Sequoia Capital", "Peak XV Partners", "Sequoia Capital India"], in canonical capitalisation. Multiple entries are an OR match. has_repeat_founder: True → require at least one founder who has previously founded or co-founded another company. has_technical_cofounder: True → require at least one technical co-founder (CTO/engineering background). founder_prior_categories: Restrict to companies whose founders previously worked at companies in these categories. Values: "faang", "big_tech", "unicorn", "top_startup", "mbb". founder_prior_companies: Restrict to companies whose founders previously worked at any of these free-text company names (resolved to canonical entities). person_roles: Restrict to companies with a CURRENT person in one of these roles. Values: "founder", "cofounder", "ceo", "cto", "cfo", "coo", "chief_other", "exec_other". person_title_contains: That person's current title contains any of these terms, e.g. ["growth"]. Each term matches whole words; a term of five or more letters also matches words that start with it ("engineer" matches "Engineering"). person_previously_at: That person previously worked at one of these companies (names or domains, e.g. ["stripe.com"]). Internships don't count. person_previous_title_contains: The title they held at that prior company contains any of these terms, matched the same way, e.g. ["cto", "chief technology"]. All person_* conditions apply to the SAME person ("a CTO who used to work at Stripe", not "a CTO, and separately someone from Stripe"). A person_* filter only matches companies with a matching person on record, so use it when the user asks for a concrete person condition; put "founder-led" style intent in `description`. Names that can't be resolved come back in `warnings`. job_cities: Restrict to companies with an OPEN JOB POSTING in these cities. This is where the company is HIRING, which is not where it is headquartered — use `cities` for headquarters. A US-headquartered company hiring in Bengaluru matches job_cities=["Bengaluru"] and countries=["United States"] at once. Use the city's common English name; a metro needs its constituent cities listed, same as `cities`. job_states: Restrict to companies hiring in these states/provinces. Full name, not abbreviation. Example: ["California", "Karnataka"]. job_countries: Restrict to companies hiring in these countries. Either an ISO2 code or a full name works — ["IN"] and ["India"] both resolve. job_departments: Restrict to companies hiring for these functions. Values: "Engineering", "Operations", "Management", "Art_and_Design", "Product", "Support", "Sales", "HR", "Marketing", "Account", "Analytics", "Data_Science_AI_ML", "Quality_Assurance", "Communication", "Finance". Use for "hiring engineers", "growing their sales team", "staffing up support". job_levels: Restrict to companies hiring at this level. "leadership" (managers and above) or "individual_contributor". Use for "hiring executives", "adding senior leadership". job_hiring: True restricts to companies with at least one open role right now, naming no role, place or level. Use it for a bare "companies that are hiring" — the other job filters all imply it, so it is redundant alongside any of them. False is the opposite side of the coverage line, not "not hiring": it restricts to companies we hold NO job-posting data for. That is roughly 5.57M companies, so use it to subtract hiring signal from an otherwise specific search, never on its own. It cannot be combined with the other job filters — those read off postings that, by definition, are not there — so any you send alongside it are dropped and reported in `warnings`. NOTE on all six job filters: they describe CURRENT hiring, drawn from a weekly scrape of company job boards, so they are a signal of growth and intent rather than a company attribute. Coverage is partial — roughly 20,000 companies have any posting data — so any job filter narrows results hard. Say so when you use one, and do not use one to stand in for a company property (a company with no open engineering role is not a company without engineers). Combining axes matches ONE POSTING when the search has no `description`: job_cities=["Austin"] with job_departments=["Sales"] then means a sales posting in Austin. With a `description` the search is answered through an index of per-company arrays, which cannot express "the same posting", so that shape can also return a company with an Austin posting and a separate sales posting. exclude_company_domains: Domains to exclude from results. Use `lookup_companies` first to resolve names to domains when needed. Unresolvable domains appear in the response `warnings`. exclude_description: ALL semantic exclusions go here — every concept the company must NOT match. Any candidate the LLM judges as matching this description is filtered out. Use this whenever the user says "exclude / not / without / no / except …", and pack multiple exclusions into one string, e.g. exclude_description="logistics providers, distributors, drinks-only manufacturers". Combined with `description` for fine-grained positive+negative semantic shaping. Do NOT phrase these as negatives inside `description`. exclude_cities: Cities to exclude, e.g. ["Bangalore"] alongside countries=["India"] for "in India but not Bangalore". Exact hard filter, unlike the semantic `exclude_description`. exclude_states: States/regions to exclude. Same semantics as `exclude_cities`. exclude_countries: Countries to exclude, e.g. countries=["United States", "Canada"] with exclude_countries=["Canada"]. exclude_funding_series: Funding-round labels to exclude — for carving a stage out of an otherwise open search, e.g. exclude_funding_series=["late", "growth"]. Same value set as `funding_series`. For "early-stage only", use the positive `funding_series=["pre_seed", "seed", "series_a"]` instead: an allow-list cannot silently let a later stage through the way an exclusion list does when it misses a slug. exclude_funding_investor: Exclude companies backed by these investors, e.g. "show me who Tiger Global has NOT funded". Same exact-match rule as `funding_investor` and no alias expansion, so list every variant you mean to exclude — a spelling you miss stays in the results. intent: Optional ranking profile applied AFTER relevance filtering. Pick the slug that best matches the user's stated or implied use case from the surrounding conversation. Omit / pass null for relevance-only ordering. Allowed slugs and when to pick each: - "sales_prospecting": general outbound — user is building a top-of-funnel list of potential customers without a specific buying-window constraint. Optimizes for companies that are actively growing, hiring, and have brand reach (broad ICP fit). - "sales_timing": "who is buying NOW?" — user wants accounts with a near-term buying window. Optimizes for recent hiring acceleration paired with healthy growth (active investment / budget release). - "sales_expansion": user already has the customer relation- ship and wants accounts ripe for upsell, cross-sell, or deepening. Optimizes for stable, steadily-growing companies with strong retention. - "competitive_tracking": user has NAMED competitors and wants to monitor their direction. Optimizes for hiring- direction shifts, momentum, brand reach, and geo footprint. - "emerging_competitor_scan": user wants to DISCOVER new entrants / rising challengers they don't yet know about. Optimizes for fast-growing, aggressively hiring companies with rising visibility. - "talent_source": recruiter / hiring manager looking for companies to poach candidates from. Optimizes for hiring in the target function, alumni footprint, team pedigree, retention. - "recruiter_employer_vet": user is evaluating whether to send a candidate to a particular company ("is this a good place for my candidate?"). Optimizes for employer retention, stability, talent demand, and brand reach. - "jobseeker_stability": job seeker prioritizing job SECURITY over upside ("is this company safe?"). Optimizes for low churn, positive net flow, retention, moderate momentum. - "jobseeker_growth": job seeker prioritizing career GROWTH ("where can my career accelerate?"). Optimizes for high-momentum companies hiring into growth functions, strong talent magnetism, recent hiring velocity. top_k: Number of results to return (1-1000, default 25). Use 25-50 for a broad list such as prospecting or a competitor scan, and under 10 when the user asks for a single best match or a quick look. Each returned strong match costs 1 credit, so match `top_k` to what the user asked for. include_partials: When True, also returns LLM-evaluated "partial" matches (close but not strong). Off by default because partials aren't billed; opt in only when the user wants exploratory context beyond strong matches. Default False. cursor: Opaque pagination token from a previous response's `next_cursor`. Pass it back to fetch the next page of the SAME search — when set, all other arguments except `top_k` are ignored server-side (the original description/filters are pinned from the first call). Omit for a new search. The response includes `next_cursor` when more results remain; pass it back as `cursor` to page through the rest without re-querying from scratch. The response also carries `results_complete`: `true` means these are ALL the companies matching the criteria (the search exhausted its candidates), `false` means it stopped at `top_k` and more exist. Omitted when unknown. It is NOT the same as `next_cursor` being absent — that token is only minted while paging, so it is missing on an ordinary first page either way. Use it when the user narrows a set you already returned: if `true`, filter the rows you have; if `false`, run a new search with the extra constraint added (passing the domains you already have as `exclude_company_domains`), because filtering a partial page silently drops every match that was never returned. When presenting results to the user, render each company's `domain` as a clickable link to the company's website (e.g. as a Markdown link to https://<domain>). Note: hard filters (location, funding, employee size, founder background, etc.) are applied exactly; `description` is the only fuzzy field, matched by an LLM verifier. Because each candidate is independently verified, the exact result set (and therefore the count and credits charged) can vary slightly between otherwise-identical calls — borderline matches may pass on one run and not the next. This is expected.
search_companies
Canonical Company Search ChatGPT Plugin FAQ
How the directory, categories and Discoverability Score work.
Read the methodologyHow do I improve Canonical Company Search's ChatGPT Plugin discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Canonical Company Search alternatives on ChatGPT?
As of 2026-11-03, Canonical Company Search competes with Add to CRM, AdvPulse, AgentData, AgentSource, AI Leads Scout, AI Vibe Prospecting, anVendor, Apollo.io and 71 more in ChatGPT B2B Prospecting & Contact Data, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.


