Skip to main content
Welcome to our June 2025 release notes! We’re halfway through the year and going full throttle launching features, cleaning data, and squashing bugs. Here’s what’s new:

Upcoming Breaking Changes

Upcoming breaking changes may impact your current processes. We are announcing them here to provide ample time for you to adjust your processes accordingly.

Deprecation of Legacy Employer Insights Fields (Company)

Change expected in: v31.0 / July 2025 Previous Announcements: Apr 2025 (v30.0), May 2025 (v30.1) Products Impacted: Company Company Fields Impacted In April 2025, we deprecated two fields in our Company Schema, which are now considered legacy. These fields will be fully replaced in July 2025 (v31.0) by the improved Company Insights fields that were released in April. Why this change? Over the past few months, we’ve made several improvements based on customer feedback requesting more display-ready and flexible insights fields. One of the key improvements is the inclusion of displayable company names instead of IDs, which makes it much easier to build visualizations like Sankey charts or other talent flow views without needing additional API calls to resolve Company IDs. The result is a simpler implementation experience and reduced API credit usage. Migration Plan
  • July 2025 (v31.0): Legacy fields will be removed.
  • April - July 2025 (v30.0 - v31.0): Both legacy and new fields are available in the Company Schema to support a smooth transition.
  • April 2025 (v30.0): New fields are available.
Action Required If you currently use the top_next_employers_by_role or top_previous_employers_by_role fields, you’ll need to update your systems to use the new fields listed below before July 2025 (v31.0): The new fields capture all the value of the legacy versions - with the added benefit of being easier to use in visual tools and product interfaces. If you have any questions or need help with the transition, please reach out to your Customer Account Team - we’re here to support you.

New Products and Features

Updated: Autocomplete API Location Parameters (API)

This month, we’re releasing some exciting enhancements to our Autocomplete API to give you more flexibility when working with location data. Based on customer feedback, we’ve added two new field options that make it easier to autocomplete not just localities but also countries and regions. What’s New You can now use the following field values when calling the Autocomplete API:
  • all_locations: This is a new option that autocompletes across all location types: countries, regions and localities. For example, searching swed can now return sweden instead of localities like stockholm, stockholm, sweden
  • location_name: This is the new name for the original location field. It autocompletes only locality-level locations (e.g., berkeley, california, united states). Using this parameter is functionally identical to the previous location field, but has been renamed for clarity.
Heads Up! location_name now replaces the previous location parameterIf you’re currently using field=location in your Autocomplete API requests, please update your implementation:
  • Use field=all_locations to expand suggestions across all location types
  • Use field=location_name to maintain the same functionality
Why This Change? Until now, autocomplete for locations only worked at the locality level - even if you were trying to find a country or region. With this update, you can now tailor results to better match your use case, whether you’re looking for cities, states or countries. No Breaking Changes: We designed this update to be backward compatible while also providing additional flexibility. The original location field has simply been copied to the new location_name parameter, without any change to functionality. You can still use the location parameter as well, but it is considered deprecated and we encourage you to use one of the alternatives instead. If you have any questions or suggestions, please let us know! We are continually striving to improve our products to ensure we deliver the best possible experience for our users.

Data Updates

Freshness

The number of jobs and locations verified in our datasets (based on the job_last_verified and location_last_updated fields). Monthly (v30.1 → v30.2) Freshness updates over the past month.

Job Changes

The number of person records where the primary job experience changed in our Person Dataset (based on the job_last_changed field). Monthly (v30.1 → v30.2) Freshness updates over the past month.

Coverage

(Full Stats: Person, Company, IP) Monthly (v30.1 → v30.2) Resume Dataset API Dataset Email Dataset Mobile Phone Dataset Company Dataset Job Posting Dataset

Commentary

  • Person
    • We saw a 25% increase the number of schools we could associate to education experiences in our Resume slice as result of our School Cleaning Improvements (see below)
  • Company
    • We saw a 27% decrease in the number of affiliated profiles we have in our Company dataset, which is consistent with previous updates. This is a low fill-rate field that is scheduled for future improvements and sourcing enhancements.
  • Job Posting Data
    • We’re now publishing stats related to our Job Posting Dataset

Improvements and Bug Fixes

Improvements

  • School Cleaning Improvements
    • We improved the canonicalization in our school dataset to improve school filtering and searching by education in the dataset. This resulted in a 25% increase in the number of school objects we are able to canonicalize.
  • Updated full_name logic
    • We updated the full_name field to include the middle_name when the first_name is one character, for example A William Barns.
  • Updated Job Title Role, Sub Role and Level Classifications
    • We improved our categorization of C Suite, Senior HR, Product/Data Owner and other job titles to support more accurate role and sub_role tags

Bug Fixes

  • Embedded null characters in Company fields
    • We implemented a fix to remove embedded null bytes in the description and headline field of Company records that was causing ingestion and parsing issues for some customers.
  • Invalid founded year
    • We added some additional cleaning logic to our Company records to remove founded dates that were set in the future
  • Location Standardization
    • We fixed a bug in our location standardization process that was leading to inflated population counts for US-based towns that have international city names (e.g. “Brisbane, California”, “London, Ohio”). This was caused by an incorrect assumption that a specific data source was only providing US-based records.