August 2026
Last updated
Was this helpful?
We are adding two new fields to the experience and education arrays to identify each entry.
experience[].id
Profile hash ID uniquely identifying each experience entry
String
education[].id
Profile hash ID uniquely identifying each education entry
String
Adding status_changed_at, an array of structs that records when a job posting's status last changed (active, inactive, or deleted). This field supports job-duration and hiring-trend analytics.
status_changed_at
Records when and how a job posting's status last changed
Array of structs
status_changed_at[].status
Job status at the time of the change. Values: active, inactive, deleted
String
status_changed_at[].changed_at
Timestamp of the status change
Timestamp
Breaking changes to Multi-source Jobs data: employment_type is changed to array<string> with normalized values (PER_DIEM → Temporary, unmapped → Other), and salary[].currency now uses ISO 4217 codes instead of symbols.
employment_type data type is changing to an array – update your flows accordingly.
employment_type
String
Array of strings
Two data fields employment_type and salary[].currency values are now normalized.
employment_type
Before: A single value, selected via priority coalesce across contributing sources.
After: A distinct array of values aggregated from all contributing sources.
Value mapping changes:
PER_DIEM
Temporary
Missing / unmapped values
Other
salary[].currency
Data quality update to salary[].currency that can disrupt symbol-matching flows.
Raw currency symbol for Glassdoor-sourced entries (e.g. $, £, k €).
ISO 4217 currency code (e.g. USD, GBP, EUR).
Indeed Jobs data field job_type values are now normalized. Filters using raw source codes (e.g. job_type = 'FULL_TIME') will stop matching, so you need to update your flows to match canonical enum values.
Raw source codes (e.g. FULL_TIME, schema.org variants, multilingual values) or absent
Canonical enum value (Full-time, Part-time, Contract, Temporary, Internship, Volunteer)+ Other fallback
Unmapped values
Other
The response shape for Agentic Search API /fast and /reasoning endpoints changing from a static, one-size-fits-all preview to a dynamic, query-aware response.
The structure of the response will change. Any integration relying on a fixed, predictable field set beyond fixed fields will need to be updated to handle a variable response shape determined by query parameters.
Fixed fields: A fixed, small set of identifying fields is always returned for every request, regardless of the query.
Company
id,
company_name,
professional_network_url,
_score
Employee
id,
full_name,
professional_network_url,
active_experience_title,
company_name,
_score
Jobs
id,
company_name,
title,
_score
Dynamic fields (query-aware): In addition to the predefined set of fields, the returned fields now vary based on the query. They include the root-level fields specified in the filter and the matched nested entries, such as particular experiences, funding rounds, or job sources that match, rather than following a fixed pattern.
Query transparency: The response now always includes the underlying Elasticsearch DSL query that produced the results.
Result cap: Results are capped at a maximum of 20 total per request.
Last updated
Was this helpful?
Was this helpful?