> ## Documentation Index
> Fetch the complete documentation index at: https://docs.crustdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Product updates and announcements for the Crustdata API.

<Update label="May 2026" description="Profile name and title fields" tags={["Feature"]}>
  ## Professional-network name and normalized title on Person profiles

  [Person Search](/person-docs/search/introduction) and
  [Person Enrich](/person-docs/enrichment/introduction) now return additional
  `basic_profile` identity fields.

  * **`basic_profile.professional_network_name`** — the display name on the
    person's professional-network profile, returned by both `/person/search` and
    `/person/enrich`. On search it is also a filterable field (not sortable). See
    the [search field reference](/person-docs/search/reference#searchable-fields)
    and the [enrich response reference](/person-docs/enrichment/reference#person_data-sections).
  * **`basic_profile.normalized_title`** — the normalized job-title object
    (`matched_title`, `department`, `sub_department`, `similarity`, `confident`)
    is now also returned by `/person/enrich`, matching the field already available
    on `/person/search`.

  Available on `POST /person/search` and `POST /person/enrich` with
  `x-api-version: 2025-11-01`.
</Update>

<Update label="May 2026" description="Richer Person Search profiles" tags={["Feature"]}>
  ## Normalized titles, education details, and logos on Person Search

  [Person Search](/person-docs/search/introduction) results now include a
  normalized job-title classification, richer education entries, and stable
  Crustdata-hosted logo permalinks for employers and schools.

  * **`basic_profile.normalized_title`** — an object with `matched_title`,
    `department`, `sub_department`, `similarity`, and `confident`. Filter on
    `basic_profile.normalized_title.matched_title`, `.department`, or
    `.sub_department` (filterable, not sortable). See the
    [field reference](/person-docs/search/reference#basic-profile).
  * **Education location and description** — each `education.schools[]` entry now
    returns a `location` object (`raw`, `city`, `state`, `country`, `continent`)
    and a `description`. The location sub-fields are filterable via
    `education.schools.location.*`. See the
    [education fields](/person-docs/search/reference#education).
  * **`education.schools[].institute_logo_permalink`** — a stable Crustdata-hosted
    school logo URL, returned for display.
  * **`experience.employment_details[].company_profile_picture_permalink`** — a
    stable Crustdata-hosted employer logo URL, so you can render company logos
    without resolving image URLs yourself. See the
    [profile-card example](/person-docs/search/examples#build-a-profile-card-with-company-and-school-logos).

  Available on `POST /person/search` with `x-api-version: 2025-11-01`.
</Update>

<Update label="May 2026" description="Follower count on Person Search" tags={["Feature"]}>
  ## Follower count on Person Search profiles

  [Person Search](/person-docs/search/introduction) now exposes a `followers`
  field on each result's `professional_network` block, alongside the existing
  `connections` field.

  * **`professional_network.followers`** — integer follower count from the
    profile. Filterable and sortable: pass it in `filters.conditions[].field`
    or `sorts[].field`. See the
    [filter and sort field reference](/person-docs/search/reference).

  Available on `POST /person/search` with `x-api-version: 2025-11-01`.
</Update>

<Update label="May 2026" description="Person Search filters" tags={["Feature"]}>
  ## Person Search: new filter operators

  [Person Search](/person-docs/search/introduction) gains two new filter
  options for the `2025-11-01` API:

  * **`(!)` — fuzzy negation.** Excludes profiles whose value contains the
    given substring (case-insensitive). Multi-word values are matched as a
    literal phrase, so `(!) "New York"` excludes profiles literally
    containing `"New York"` but **not** `"New Yorker"`. To exclude on each
    word independently, send separate `(!)` conditions inside an `and`
    group. See the [operator reference](/person-docs/search/reference#-fuzzy-negation)
    and a [worked example](/person-docs/search/examples#exclude-profiles-matching-a-substring).
  * **`geo_distance` accepts `lat_lng`.** Supply explicit coordinates as
    `[lat, lng]` to skip geocoding. When both `location` and `lat_lng` are
    provided, `lat_lng` wins. See the
    [`geo_distance` reference](/person-docs/search/reference#geo_distance--radius-around-a-point)
    and the [`lat_lng` example](/person-docs/search/examples#search-by-explicit-coordinates).

  Both operators are available only on `POST /person/search` with
  `x-api-version: 2025-11-01`.
</Update>

<Update label="May 2026" description="API version 2025-11-01" tags={["Feature"]}>
  ## 🚀 New API version: `2025-11-01`

  We are launching a new, versioned API that replaces the legacy
  `/screener` and `/data_lab` endpoints. Every product — Company, Person,
  Job, Web, and Social Post — now lives under a consistent, purpose-built
  surface area.

  ### What's new

  * **Versioned endpoints.** Every call requires the
    `x-api-version: 2025-11-01` header, so future changes ship without
    breaking existing integrations.
  * **Bearer authentication.** `Authorization: Bearer <key>` replaces the
    legacy `Token` scheme across every endpoint.
  * **Structured error envelope.** A consistent `{ error: { type, message, metadata } }`
    shape across every endpoint.
  * **Cursor-based pagination.** Opaque `next_cursor` replaces numeric
    `offset` on search endpoints.
  * **Match-result envelope for enrich.** Enrich responses now return
    `matches[]` with a `confidence_score` per match.
  * **Nested, neutral response sections.** Flat top-level keys are grouped
    under sections like `basic_info`, `employee_reviews`, and `funding`.

  ### Migrating from the legacy API

  Every legacy `/screener` and `/data_lab` endpoint has a current
  replacement. The [Migration guides](/migrations/overview) map each
  legacy endpoint to its new equivalent and walk through request keys,
  field renames, type changes, and response-shape differences.
</Update>