Product updates

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.

Previous limitations:

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

• Unstructured data - Location information wasn't standardized
• 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.

Example improvement:

• 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

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 array per job, replacing fragmented fields like country_codes, state_code, location, latitude, longitude, etc. This enables first-class support for multi-location jobs and consistent geo data.

• Structured array of location objects
• Consistent normalization across sources
• 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.).

Previously, you could set up webhooks to export company data to external tools like Clay, N8N, and Zapier, but you'd miss out when new companies matched your search criteria.

We've now added continuous monitoring – your webhooks will automatically send events whenever fresh companies are discovered that match your search parameters.

This means you'll get instant notifications when new companies start adopting specific technologies (like Salesforce or Hubspot) or entire technology categories (such as CRM Platforms).

We introduced property_exists_and and property_exists_or filters in both Jobs and Companies search endpoints.

Use them to require fields like final_url, hiring_team, company_object.domain, company_object.linkedin_url, or employment_statuses (jobs) to be set.

We added a technology_slugs array for each job returned by the Jobs Search endpoint. It contains the technology slugs detected in the job_title, job_description, or job_url.

Read more about how we source our technographic data