Product updates

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 for each job. It's an array of Location objects with comprehensive geographic data based on the GeoNames database.

Each location object includes:

Core Location Information:

• id – ID of the location in GeoNames.
• name – The name of the location. If it's a city, it will be the city name; if it's a country, it will be the country name; if it's a region, it will be the region name, etc (e.g., "New York City", "Germany")
• type – The type of location (e.g., "city", "country", "region")
• feature_code – GeoNames feature code (e.g., "PPL" for populated place, "ADM1" for first-order administrative division, "PCLI" for country...). Check all the possible feature codes here.
• feature_class – GeoNames feature class (e.g., "P" for cities or towns, "A" for countries, states, regions...). Each one of the possible feature classes is each one of the sections in here.

Geographic Coordinates:

• latitude – Geographic latitude coordinate for precise mapping
• longitude – Geographic longitude coordinate for precise mapping

Administrative Divisions:

• admin1_name – First-level administrative division name (e.g., "California", "New York")
• admin1_code – First-level administrative division code (e.g., "CA", "NY")
• admin1_id – GeoNames ID for the first-level administrative division
• admin2_name – Second-level administrative division name (e.g., county or district)
• admin2_code – Second-level administrative division code
• admin3_code – Third-level administrative division code
• admin4_code – Fourth-level administrative division code

Country and Continent:

• country_code – ISO 3166-1 alpha-2 country code (e.g., "US", "DE")
• country_id – GeoNames ID for the country
• continent – Continent code (e.g., "NA", "EU", "AS")

Here's an example location object:

[
    {
        "admin1_code": "NY",
        "admin1_id": "5128638",
        "admin1_name": "New York",
        "continent": "NA",
        "continent_id": "6255149",
        "country_code": "US",
        "country_id": "6252001",
        "feature_class": "P",
        "feature_code": "PPL",
        "id": "5128581",
        "latitude": 40.71427,
        "longitude": -74.00597,
        "name": "New York City"
    }
]

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.).

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

We added a new property_exists_or filter to both Jobs and Company Search endpoints. This filter allows you to find records where at least one of the specified properties exists.

We also improved the company_type filter. When filtering by direct_employer, we now exclude recruiting agencies to give you more accurate results when looking for direct hiring companies.

We've expanded our job coverage with new sources in France and Asia-Pacific:

• Welcome to the Jungle - major French 🇫🇷 job board
• JobsDB and JobStreet covering Hong Kong 🇭🇰, Malaysia 🇲🇾, Singapore 🇸🇬, Philippines 🇵🇭, Indonesia 🇮🇩, Thailand 🇹🇭, New Zealand 🇳🇿

These additions significantly improve job coverage in French-speaking markets and key Asia-Pacific economies.