Skip to content
  • There are no suggestions because the search field is empty.

LinkedIn field removed from People Search

Applies to: Firmable API, POST /people/search

Effective: 6 October 2026

What changed

The linkedin field is no longer returned in the People Search response. Every other field the endpoint returns is unchanged, and the endpoint itself continues to work exactly as before.

Why

People Search is designed to return match candidates and availability flags. It tells you which people match your criteria, and whether contact data exists for them, rather than returning the data itself. That is why the response carries has_email, has_phone and has_mobile as booleans rather than values.

The linkedin field was the one profile-level value sitting in that response. Removing it makes the endpoint consistent with how the rest of it already behaves. Profile detail, including the LinkedIn URL, is returned by People Enrichment.

The response, before and after

Before

[
  {
    "person_id": "fp000000067890",
    "position": "Chief Marketing Officer",
    "company_name": "Example Pty Ltd",
    "linkedin": "person_slug",
    "has_email": true,
    "has_personal_email": true,
    "has_phone": true,
    "has_dnd_phone": false,
    "has_mobile": true
  }
]

After

[
  {
    "person_id": "fp000000067890",
    "position": "Chief Marketing Officer",
    "company_name": "Example Pty Ltd",
    "has_email": true,
    "has_personal_email": true,
    "has_phone": true,
    "has_dnd_phone": false,
    "has_mobile": true
  }
]

Every search result still carries person_id. Pass it to People Enrichment:

GET <https://api.firmable.com/people?id=fp000000067890
Authorization: Bearer YOUR_API_KEY

The response includes linkedin as a full profile URL, along with social_media.linkedin for handle, connections and follower detail.

If your integration uses the LinkedIn URL as a lookup key

Some integrations take the URL from a search result and use it to call People Enrichment with ln_url or ln_slug. That pattern needs one change: pass person_id to the id parameter instead.

Before

POST /people/search    -> read linkedin from each result
GET  /people?ln_url=https://www.linkedin.com/in/person_slug

After

POST /people/search    -> read person_id from each result
GET  /people?id=fp000000067890

The enrichment response is identical either way, and credit consumption is unchanged.

Common questions

Is People Search being retired?

No. The endpoint stays, and only the one field is removed.

Do ln_url and ln_slug still work on People Enrichment?

Yes. If you hold LinkedIn URLs from your own records or from an earlier enrichment, you can keep using them as lookups.

Does this affect data I have already stored?

No. Records you have already retrieved are yours and are unaffected.

Does this affect Company Enrichment?

No. GET /company is unchanged, including the company LinkedIn handle.

Does this affect the app, the MCP connector or the CRM integrations?

No. This change is limited to the POST /people/search API response.

Does this change how many credits I use?

The change itself does not alter credit pricing. If your workflow previously read the LinkedIn URL straight from search results and now enriches by person_id instead, you will be making enrichment calls you were not making before, and those consume credits in the usual way. Talk to your Customer Success Manager if you would like to look at your allocation.

Timing

The change takes effect on 6 October 2026 for all customers at the same time.