LinkedIn API — Profile Data Change

The location Field Is Being Removed From /v2/me and /v2/people

LinkedIn's Profile API is dropping the top-level location field (the plain-text string like “San Francisco Bay Area”) from both /v2/me and /v2/people responses. There is no error, no deprecation warning in the response body, and no fixed removal date published — integrations that still read this field simply start receiving an empty or null value.

What Changes vs. What Replaces It

⚠ What Breaks Silently

  • The flat-string location field on /v2/me and /v2/people stops returning a value
  • No exception, no error code — your existing code keeps running against an empty field
  • Any logic keyed on that string (targeting, display, enrichment) degrades quietly, not loudly
  • Teams often notice only after a downstream report or dashboard looks wrong

✓ The Replacement Field

  • Use geoLocation instead — already live on both endpoints today
  • Request it with a projection: projection=(geoLocation(geo~,autoGenerated))
  • The display name resolves from the linked geo~ object, not a flat string
  • Per LinkedIn's own Profile API reference, this is the documented migration path

Where This Quietly Breaks Real Integrations

  • Audience or segmentation logic that keys off a free-text location string instead of a structured geo ID
  • CRM and lead-enrichment pipelines that store location as a plain string at sync time
  • Profile display UIs that render the field directly without a fallback for an empty value
  • Hardcoded field lists in older integration code that were never updated to request the geo~ projection
  • Code that treats an empty string as valid data instead of a signal to re-fetch via geoLocation

How to Migrate Before It Breaks in Production

1
Audit every call to /v2/me and /v2/peopleSearch your codebase and API logs for any request or response mapping that still references the flat location field.
2
Switch the request to geoLocationUpdate the projection on affected calls to projection=(geoLocation(geo~,autoGenerated)) so the linked geo object is returned alongside the reference.
3
Resolve the display name from the geo~ objectParse the linked object rather than expecting a ready-made string — the shape of this response is different from the old flat field.
4
Add a null-safe fallbackgeoLocation can still be empty for members who never set a location on their profile — that is expected, not a bug in your integration.
5
Re-test downstream logic before deployingAny targeting, personalization, reporting, or enrichment flow that depended on the old field needs a fresh pass with the new response shape.

Mistakes That Slip Through Code Review

  • Assuming an empty location value means the API call failed, rather than expected behavior
  • Migrating the read call but never re-testing the downstream logic that consumed the old field
  • Treating this in isolation — LinkedIn is separately retiring Legacy Geo URNs for ads targeting by August 31, 2026, a related but distinct cleanup on the same API surface
  • Caching the old flat-string value permanently instead of re-fetching it through the new field

What a Correct Migration Looks Like

Every call that used to read the flat location field now requests geoLocation with the correct projection, resolves the display name from the linked object, handles a genuinely empty value gracefully, and has had its downstream logic re-tested against the new response shape — before LinkedIn's removal reaches production traffic, not after.

This is a small field-level change on paper, but it is exactly the kind of silent API change that is easy to miss during a routine LinkedIn integration review — nothing throws an error, so nothing forces the fix until a report or feature quietly stops working. It sits alongside a wider pattern of profile and audience-data changes LinkedIn has been rolling into its Marketing API this year.

For a full review of your LinkedIn integration’s API surface, OAuth scopes, and app review status — not just this one field — see the LinkedIn API Setup Service. For the related Advertising API access-tier process, see LinkedIn Advertising API Standard Tier.

This content reflects publicly available LinkedIn developer documentation (Microsoft Learn, li-lms 2026) and is not an official LinkedIn or Microsoft publication. Field behavior and removal timing are controlled solely by LinkedIn and may change without further notice.