Skip to main content
​
New

​
Week of September 25

​
New: fetch your stored leads

The new /signal/leads endpoint returns the leads your engagement signals have found, so you can read past leads instead of only receiving them by webhook or email. Filter by signal, lead score, keyword, engagement type, name or headline, and date, sort by date or score, and page through your full history.It is free, and it returns the lead fields your webhooks carry, plus a stable id, the signal_id, and icp_match_details.
​
NewImproved

​
Week of September 23

​
New: person_activity signal

The new person_activity signal tells you when a person you track reacts to or comments on any post on LinkedIn. Each alert includes the post, its author, and the comment text. Choose reactions, comments, or both with activity_types.

​
Several signals of one type, with names

You can now run several job_change, new_post, or person_activity signals, for example one for champions and one for churned customers. Each has its own profiles, baseline, and alerts.
  • /signal/create returns a signal_id for every signal type. Pass new_signal: true to start another signal of a type you already have, or signal_id to add profiles to a specific one.
  • Every signal type accepts an optional name, and the new rename action on /signal/update changes it.
  • /signal/update and /signal/delete take signal_id for profile signals. Without it, a request still means your only signal of that type, so existing integrations keep working.
  • Webhooks for profile signals now include job_id and job_name.

​
Improved: signals run on schedule

Signals now start at their scheduled time. Before, busy periods could delay a run by several hours.

​
Docs: webhook signatures and retries

The webhook signature header is sha256= followed by the hex digest; the verification examples now include the prefix. The retry schedule now shows all 7 attempts, and the payload reference shows the fields that job_change and new_post webhooks actually send.
​
BreakingImprovedNew

​
Week of September 19

​
Person: the same response shape on every request

Person now returns the same set of fields, in the same order, on every request. Every entry in a list (experience, education, certification, publication, project, volunteering, honors_and_awards, organizations, patents, language, courses) has the same keys. Before, a field could be present on one request and missing on the next for the same profile. That no longer happens, including for profiles served from cache.A field with no value is still present:
  • "" for text
  • [] for lists
  • null where the value is not known
Check a field’s value, not whether the key exists.

​
Breaking changes

​
New fields

Profile
  • Location: address_without_country, address_country_only, country_code (ISO 3166 alpha-2, e.g. "US") and location_city. The existing location, country, address_with_country and address are now present on every response too.
  • Industry: industry and industry_name (always the same value), plus industry_urn.
  • Pictures: profile_pictures / avatar_all_dimensions and background_pictures / background_picture_all_dimensions. Both forms are always present and list the same images.
  • Other fields now present on every response: total_experiences, primary_locale, is_hiring, is_memorialized, show_premium_badge, courses, updates, contact_info. A flag that could not be read is null, not false.
  • Birthday: birthday is filled with the month and day when the profile shows them.
Experience
  • workplace_type: "On-site", "Remote" or "Hybrid", when the role shows it.
  • company_username and company_urn on every role.
  • When a company is known to us, company_id, company_username and company_url identify it the same way on every request. company_url takes the form https://www.linkedin.com/company/<name>/.
  • company_headcount_range always uses the form "11-50 employees".
Other sections
  • education[].university_urn.
  • publication[]: published_on_date ({ "day", "month", "year" }, 0 when unknown), publishing_date ("Nov 11 2014") and authors.
  • project[]: start, end, date, url, contributors, associated_with and subtitle.
  • volunteering[]: started_on, ended_on, start_date, end_date, duration, is_current_position, description, cause, and organization alongside company_name.
  • certification[]: both naming styles are always filled, issuer / authority / company_name, issued_on / started_on and expires_on / end_date.
  • organizations[]: name / title, position_held / subtitle, start and end.
  • honors_and_awards[].issued_on.

​
Fixes

  • Education dates written with months (e.g. "Sep 2023 - Present") were being dropped. They are now returned, including the month.
  • Experience lists for profiles with a long work history are more complete.
  • use_cache: "never" now always fetches the profile fresh. Before, repeating the same request within a few minutes could return the previous response.
  • A role whose only location was its workplace type (e.g. “Remote”) now gets the profile’s location, like any other role without one.