Job title matching

Job title filters in people search are keyword matching, not a search engine for jobs. They match tokens, expand a curated set of synonyms, and never forgive typos. Once you know the rules, the surprises stop: the query that returned 5 people returns 2,600, and the query that timed out stops timing out.

What it does

Three title filters reach the API, all with the same matching core:

• Job title filter (jobTitleV3, and the per-company jobs entries): every word in your query must appear somewhere in the person's title, in any order. "Engineer Software" matches "Software Engineer".
• Exact mode (exact: true on a plain title rule): the title must equal your string after trimming and lowercasing. Nothing else.
• Keywords filter (keywords): each keyword is a phrase that must appear in one piece, words adjacent and in order, inside a profile field you enable.

Titles match current roles only by default. To match past roles, set the employment status filter or use a jobs entry scoped to past tenure.

No typo tolerance, anywhere

Title matching, keyword matching, and exact mode all run with typo correction disabled. "Enginner" matches nothing. Normalize your input first; the job-title typeahead (job title synonym expansion) helps here.

Synonyms expand in both directions

A curated acronym map expands at query time, both ways, on the title filter path: CTO matches "Chief Technology Officer", and "Chief Technology Officer" matches profiles titled CTO. MTS matches "Member of Technical Staff". The common families are covered: C-suite, SWE variants (including swe), VP, sdr, bdr, tpm, sre, devops.

Two things synonyms do not apply to: the keywords filter, and exact mode.

Inputs and outputs

A title rule in plain form:

{
  "searchParams": {
    "jobTitleV3": {
      "rules": [{ "plain": { "title": "software engineer", "anyOf": true } }]
    },
    "country3LetterCode": { "noneOf": ["IND"] }
  },
  "pageSize": 25
}

Exact equality:

{
  "searchParams": {
    "jobTitleV3": {
      "rules": [{ "plain": { "title": "member of technical staff", "exact": true } }]
    }
  }
}

Exact mode compares after trim and lowercase only. Punctuation and stop words are preserved: exact "VP of Engineering" does not match "VP, Engineering".

Combination rules: functional and cartesian

Two rule shapes generate title lists for you before matching runs.

Functional rules combine a seniority axis with keyword axes using our own smart templates: { "seniority": ["c-suite"], "keywords": ["marketing"] } expands to "Chief Marketing Officer" and related forms. Leave seniority out and sensible defaults apply (c-suite expands to Founder, CEO, CTO, and friends). Each functional rule generates at most 75 titles; a keyword that already carries its seniority word passes through unchanged.

Cartesian rules multiply out keyword sets you supply. Give keywordArrays two or more arrays and every combination across the arrays becomes one title:

{
  "rules": [
    {
      "cartesian": {
        "keywordArrays": [
          ["senior", "staff", "lead"],
          ["software", "platform", "infrastructure"],
          ["engineer"]
        ]
      }
    }
  ]
}

Three by three by one generates nine titles: "senior software engineer", "staff platform engineer", "lead infrastructure engineer", and the rest of the grid. It is the right tool when the title space you want is a product of sets you can name, and you would otherwise paste the list in by hand.

Rules of the road for cartesian:

• Generated titles match like plain titles: token-AND matching with synonyms, never exact mode (exact is unavailable on generated rules).
• Each rule caps at 500 generated titles. Combinations multiply fast; a 10 by 10 by 6 grid already exceeds the cap and gets truncated.
• Fan-out costs latency. Every generated title becomes a match clause, and clause-heavy queries scale linearly in search time. Prefer the smallest grid that covers your intent, and count before you search.

Use plain anyOf lists when you already have the titles; use functional rules when seniority shaping is the job; use cartesian when the titles are a cross-product you would otherwise enumerate client-side.

When the keywords filter is the better tool

Title filters match tokens anywhere in the title and expand synonyms, so they cast wide: "member of technical staff" also surfaces acronym forms like "Software Engineering MTS", and they cannot subtract seniority. The keywords filter is the alternative for precision: each phrase must appear in order, inside a single field you explicitly choose.

Say you want everyone titled "Member of Technical Staff" at two specific companies. The title filter returns only profiles whose titles carry those tokens literally. The keywords filter, scoped to current job titles, returns the full population:

{
  "searchParams": {
    "keywords": {
      "containsAny": ["member of technical staff", "member technical staff"]
    },
    "keywordSearchOptions": {
      "fieldsToSearchOver": {
        "currentJobTitles": true,
        "headline": false,
        "summary": false,
        "industry": false,
        "currentJobSummaries": false,
        "currentCompanyNames": false,
        "pastJobTitles": false,
        "pastJobSummaries": false,
        "pastCompanyNames": false,
        "interests": false,
        "skills": false,
        "education": false,
        "publications": false,
        "certifications": false,
        "articles": false,
        "patents": false,
        "courses": false,
        "projects": false,
        "volunteering": false,
        "languages": false
      }
    },
    "currentCompanies": [
      { "linkedinOrgID": "11130470" },
      { "linkedinOrgID": "7936402" }
    ]
  },
  "pageSize": 25
}

Three rules make this work:

• Set every field explicitly. 18 of the 20 keyword fields default to on and omitted fields stay on; leaving summaries and headlines in scope can balloon the same query several-fold. Unknown field names are silently ignored, so a typo'd field stays at its default.
• Order words the way titles are written. "technical staff member" is a different, much larger phrase world than "member of technical staff". Include the stop-word-free variant ("member technical staff") in containsAny for recall.
• Subtract with containsNone. Phrases match inside longer titles ("VP, Member of Technical Staff" still matches), so put the variants you do not want, such as "senior member of technical staff" or "vp", there.

Run the count operation with identical parameters first (1 credit) to preview the result-set size, and give count and search generous client timeouts (60 to 120 seconds): phrase queries over many fields are the heaviest this endpoint family runs.

Using it effectively

• Count before you search. Run the count operation with the same parameters first; it costs a single count credit and shows how big the set is before you pay per result. For recurring versions of the same query, save it as a saved search; scheduled runs follow the same count, then search rules.
• Give phrase queries generous timeouts. Keyword-heavy queries over many fields multiply the work per page; 60 to 120 seconds is a safe client timeout for counts and searches like this.
• Want equality? Use exact mode. The plain title filter is containment: "Software Engineer" also returns every "Senior Software Engineer".
• Want breadth? Expand, don't hope. Run the job-title synonym expansion on your seed title and feed the variants back as additional anyOf terms. Its suggestions are advisory: the search-time synonym map is a different, smaller list, so a suggestion is not automatically expanded at query time.
• Scope by company for team snapshots. Combine the keywords filter with a current-companies constraint (by LinkedIn org ID, domain, or URL) to get "everyone with this title at these companies" in one query.
• Watch current vs past. Title filters default to current roles only; past-title keyword fields only see roles that have ended.

Use cases

• Building a hiring pipeline for one exact title (exact mode, count first).
• Talent mapping across acronyms and variants (synonyms plus expanded variants).
• Cleaning up an over-broad keyword query by switching fields off explicitly.

Operations

Search credits are charged per result returned; counts are 1 credit. See Billing for per-operation pricing, and Search for the rest of the filter surface.