Product updates

The seniority field in every job object in the Job Search endpoint can take one of these 5 values:

• c_level
• staff
• senior
• mid_level
• junior

Previously, seniority was not being correctly assigned for certain job titles:

• All “Vice President” roles were sometimes misclassified, being considered as mid-level roles, and all "VP" roles were considered C-Level.
• The “Staff” seniority label was applied too broadly, including roles like “Staff Nurse” or “Staff Physician” that do not represent Staff-level IC (Individual Contributor) positions.

With this update, seniority assignment has been improved:

• All “Vice President” roles are now consistently marked as Senior, rather than C-Level. While VP might sound like a C-Level title, in many organizations—especially banks and financial institutions—VP is a very common title that better aligns with Senior-level responsibility.
• The “Staff” seniority is now reserved only for explicit Staff-level IC roles, such as “Staff Engineer” or “Member of the Technical Staff.”
• Roles like “Staff Nurse” or “Staff Physician” are no longer misclassified as Staff; instead, they are mapped to more appropriate levels, often mid-level.

We've added a new exclusion filter called job_description_contains_not to the Jobs Search endpoint.

This filter helps you exclude jobs that contain specific words in their descriptions. Here's how it works:

• Whole word matching: It only matches complete words using word boundaries, so searching for "quality" won't exclude jobs mentioning "inequality"
• Smart case handling: Searches are case-insensitive by default, but if you use uppercase patterns, we'll respect the exact casing
• Multiple exclusions: You can exclude jobs containing any of several different words at once

Perfect for filtering out roles you're not interested in, like excluding "internship" positions or "remote" jobs when you prefer in-office work.

Previously, when using the Jobs Search endpoint, you needed to include at least one of these required filters:

• posted_at_max_age_days
• posted_at_gte
• posted_at_lte
• company_name_or

We've expanded the list of required filters to include two new options:

• company_domain_or
• company_linkedin_url_or

Now you can search for jobs from specific companies using their domain or LinkedIn URL, without needing to specify dates or company names. This gives you more flexibility when targeting jobs from particular organizations.

We've just released our new locations catalog endpoint, making it simple to find and search through location data when you need precise geographic targeting.

This is especially useful when you're integrating our API into your application and want to use location-based filtering:

1. A user searches for "Paris" in your app
2. Your system calls GET /v0/catalog/locations?name=Paris to get Paris's location ID
3. You use that ID with our Jobs endpoint using "job_location_or": [{"id": "XXX"}] to return jobs only in Paris

The workflow is straightforward and keeps the complexity hidden from your users.

🚧 Beta Feature: This new filtering capability is currently available for recent jobs (posted within the last 3 months ±). We're actively expanding coverage to older jobs and improving the system based on user feedback. 🚧

We've introduced new location filters job_location_or and job_location_not to the Jobs Search endpoint and Company Search endpoint for precise geographic targeting in job searches.

These new filters address several limitations of the existing location_pattern_or filter:

• Greater precision - Target specific cities, states, or regions with exact accuracy. When searching for San Francisco, results will be limited to California, U.S., and won't include other cities with the same name elsewhere in the world
• Hierarchical location searches - Search for "Europe", "China" or "California" and get all jobs within that region. The hierarchical location data enables searches at any level (country, state, province, city, etc.). This wasn't possible with the previous text-based approach, which couldn't understand location hierarchies
• Multi-language location searches - Search for locations in different languages using the same location IDs, ensuring consistent results regardless of the search language. With the previous string matching approach, searching for "Germany" wouldn't match all occurrences since "Deutschland" could be used instead
• Cross-country city searches - Search across multiple cities in different countries simultaneously. This supports state/city queries across countries (e.g., Alabama, US and London, UK) in a single search request
• Improved flexibility - Easily combine multiple location criteria or exclude specific areas
• Better performance - More efficient searches using indexed location data
• Structured data - Uses normalized location IDs instead of text pattern matching

You can use the locations catalog endpoint to search for the IDs of your desired locations.

Previously, you could only filter companies in the Technographics endpoint using company_domain or company_name. Now you can also use company_linkedin_url as a filter.

If you're already working with LinkedIn URLs as your primary company identifier, you no longer need to make an additional call to the Company Search endpoint to find the domain or name first. You can now query the Technographics endpoint directly with the LinkedIn URL.

This streamlines your workflow and reduces the number of API calls and API credits needed to get technology data for companies.

We've identified and resolved an issue affecting employment status data across several job sources. Previously, the employment status field (which indicates whether positions are full-time, part-time, contract, etc.) was appearing empty for certain job listings, even when this information was available from the source.

This has now been fixed for all jobs discovered from September 2, 2025 onwards, ensuring that employment status data is properly captured and displayed when available from job sources.

For older jobs, we'll reprocess them in the coming weeks to backfill this missing data.

We've enhanced location filtering in the Jobs Search endpoint and job filters in the Company Search endpoint by improving how location_pattern_or and job_location_pattern_not filters work.

• Before: Searching for "California" only matched jobs with "California" in the location string
• Now: Returns all jobs from any city within California (San Francisco, Los Angeles, Sacramento, etc.) or cities containing "California" in the name

Previous limitations

Location filtering used only the basic location field, which had several limitations:

• Unstructured data - Location information wasn't standardized. For example, in some jobs the location was "San Francisco, CA" and in others it was "San Francisco, California".
• Inconsistent details - State names, city names, and country information weren't always available or standardized
• Limited search accuracy - You could only match exact text patterns in the location string

What's improved

These filters now search across the enhanced locations attribute (introduced in our August 8 update) instead of just the basic location field. This provides more accurate geographic matching using structured location data with normalized city and state information.

This enhancement leverages our location normalization process to deliver significantly better geographic search accuracy across all job sources.

Fixed double-escaped Markdown in YCombinator job descriptions so formatting like bold renders correctly.

Fixed Join job locations so they reflect the actual job location rather than the company HQ.

Fixed missing salary display for a small subset of jobs. The salary_string field was empty despite salary data being present, which left the UI column blank and impacted API results. Now any job with min_salary or max_salary includes a populated salary_string. This field represents the salary range in a human-readable and localized format.

When building our company dataset, we combine information from multiple sources. One of the most important pieces of company information we provide is the domain, and we made 2 major improvements to it:

• Better identification of URLs from social sites, link shorteners, etc. - A significant number of companies set their LinkedIn URL to a link to bit.ly, linktr.ee, sites.google.com, facebook.com, instagram.com... When extracting the domain from those URLs, we'd say that Bit.ly, Linktree, Google, Facebook or Instagram (among others) were associated to tens of thousands of companies, which is obviously not the case. This is now fixed. For example, bit.ly was originally associated to thousands of companies because many of them had set their LinkedIn URL to a bit.ly link. Now it's only associated with the correct company, as shown in this bit.ly domain search.

• Better company linkage to companies with similar names - Previously, in many cases we'd match small companies with names similar to those of larger companies to the larger company. For example, we'd say that the domain of a company named AIR+ was airbnb.com, which is also not true. Now, the name similarity has to be much higher for us to consider two companies to be the same.

New employment_statuses_or filter in the Jobs Search endpoint and Company Search endpoint. Pass an array like ["full_time", "seasonal"] to match any of the provided statuses. Leave empty or pass null to include all jobs.

New employment_statuses option for property_exists_or and property_exists_and in the Jobs Search endpoint and Company Search endpoint. Filter to only jobs where employment status information is available and populated.

The Jobs Search endpoint now returns a locations property per job with the following fields:

• City – The specific city where the job is located
• State – The full state name (e.g., "California")
• State Code – The abbreviated state code (e.g., "CA")
• Country Code – The standardized country code (e.g., "US")
• Address – The complete street address when available
• Postal Code – The ZIP code or postal code for the location
• Latitude – The geographic latitude coordinate for precise mapping
• Longitude – The geographic longitude coordinate for precise mapping

We've built a location parsing system that works like a universal translator for addresses. It doesn't just standardize formats—it also adds missing geographic coordinates and validates addresses to create a complete location profile for every job posting. This turns scattered location fragments into precise, searchable geographic data.

See our location normalization docs