Product updates

🚧 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

We launched an improved affiliate program with higher commission rates and a self-service portal. See the announcement post in the blog.

We've removed the default limit in the Technographics endpoint on the number of technologies returned.

Previously, the API only returned 25 technologies per request, forcing you to make multiple calls to get complete technology data for most companies.

Since retrieving full tech stack is the most common use case, we've simplified the API to return all technologies by default. There is no need to pass the page and limit parameters anymore.

The API dialog let you get the curl command to call the API from the App. We've made 2 improvements to it:

• Body request now properly supports special characters like apostrophes.
• Displays curl for other requests (exports, technographics, etc.).