Beyond the News
Sign in
Web DevelopmentMarketing & DistributionDeveloper Tools Active dossier

LinkedIn is sunsetting the Profile API `location` field in favor of `geoLocation`

LinkedIn is removing the top-level `location` field from `/v2/me` and `/v2/people`. Integrations that still read the legacy field can begin receiving an empty or null value and need to request `geoLocation` plus its decorated Bing Geo entity instead.

Reviewed and published by Lars Jansen Updated 5 min read
Comment
First published

Key details

  1. LinkedIn says the top-level `location` field is being removed from `/v2/me` and `/v2/people`.
  2. Partners relying on the field may begin receiving an empty or null value.
  3. The supported replacement is the `geoLocation` field.
  4. A display name can be retrieved by decorating the referenced Bing Geo entity, for example with `projection=(geoLocation(geo~,autoGenerated))`.
  5. The change is documented in both LinkedIn Marketing Developer and Compliance Program release notes.
  6. The Profile API field sunset is distinct from the August 31 Legacy Geo Ads Targeting cutoff already covered by BTN.

What builders should take away

  1. Search response parsers, database mappings and templates for reads of the top-level LinkedIn `location` field and move them to `geoLocation`.
  2. Add a contract test that fails when required profile fields unexpectedly become null even if LinkedIn returns HTTP 200.
  3. If your application needs the location display name, request the decorated `geo~` entity and test its nested response shape rather than merely renaming one JSON key.
  4. Backfill or version stored profile schemas carefully if geography is used in CRM segmentation, compliance archives or analytics.
  5. Keep the Ads Targeting geo migration on a separate checklist; fixing Profile API `location` does not fix Legacy Geo campaign payloads.

What changed

LinkedIn's August 2026 developer release notes say the top-level `location` field is being removed from the v2 Profile API responses returned by `/v2/me` and `/v2/people`. Partners that rely on the legacy location object may begin receiving an empty or null value. LinkedIn directs integrations to the already available `geoLocation` field and, when they need the human-readable location name, to request the decorated Bing Geo entity using a projection such as `geoLocation(geo~,autoGenerated)`. LinkedIn lists the change alongside its wider Bing Geo migration, but it is distinct from the August 31 Legacy Geo retirement for Ads Targeting that BTN already covers.

Why it matters

This is a quiet breaking change because an HTTP request can remain successful while application data disappears. Profile enrichment, CRM synchronization, compliance archives and other integrations that assume `location` always contains a display value can begin storing nulls, suppressing geography-based logic or rendering blank fields without throwing an obvious API error. Builders should therefore treat field-shape migrations as schema changes, not only watch for endpoint retirement or HTTP failures.

The replacement is a different structured field

LinkedIn is moving Profile API geography from the old top-level `location` representation to `geoLocation`, which references the platform's Bing Geo taxonomy. Applications that only need the structured value can use the new field directly; those that need the display name must request the decorated geo entity rather than expecting the old location string/object.

Old clients can fail silently

LinkedIn warns that partners relying on `location` may begin receiving an empty or null value. That means ordinary uptime monitoring can remain green while downstream records lose geography. Schema-level assertions and representative API-response tests are more useful than relying only on HTTP status codes.

This is not the same migration as Ads Legacy Geo

BTN's existing LinkedIn dossier #185 covers the 1,000-segment cap and the hard retirement of Legacy Geo identifiers used for Ads Targeting. The Profile API change affects `/v2/me` and `/v2/people` response fields instead. Both are part of LinkedIn's broader move toward Bing Geo, but they break different integrations in different ways.

Compliance integrations receive the same warning

LinkedIn's Compliance Program release notes independently call out the Profile `location` field sunset and the migration to `geoLocation`. That matters for partners that archive or monitor regulated-member activity because their stored profile snapshots and parsing logic can depend on the same legacy field.

What to watch next

  • When LinkedIn removes the legacy field completely rather than allowing a mixed period of empty/null responses.
  • Whether other profile fields that still use older location taxonomy are migrated to Bing Geo on separate timelines.
  • SDK or schema updates that remove `location` from generated models.
  • Reports of downstream partner breakage caused by successful API responses containing null geography.
  • Further consolidation of LinkedIn profile, ads and compliance geography around one Bing Geo schema.

Still unclear

  • LinkedIn's current August release notes describe the field as being removed and warn that null/empty responses may begin, but do not state one universal moment when every partner will stop seeing the legacy value.
  • The exact impact depends on which Profile API fields an approved LinkedIn application is permitted to access.
  • Bing Geo decoration changes the response shape as well as the field name, so migration effort varies by parser and storage model.

Sources

Direct reading behind this dossier.

2 sources
Recent Marketing API Changes
LinkedIn / Microsoft Learn primary_documentation

Primary August 2026 developer release notes documenting the Profile `location` removal, possible null/empty responses and `geoLocation` replacement.

Compliance Program Release Notes
LinkedIn / Microsoft Learn primary_documentation

Independent LinkedIn developer documentation surface repeating the Profile.location sunset and Bing Geo migration for compliance integrations.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Web Development

Reddit is moving third-party apps off its Public Data API and onto Developer Platform

Reddit has made the direction of its API platform explicit: existing API apps should register now, with an August 30 cutoff for possible $1,000 porting-bounty eligibility and a broader September 30 registration request. The actual migration is later, but builders need to inventory dependencies and missing Devvit capabilities now.