LinkedIn company IDs now work in company and job search

LinkedIn identifies a company page two ways: by its vanity slug (linkedin.com/company/deloitte) and by its numeric company ID (linkedin.com/company/1038). Both open the same page, and which one you end up storing depends on where you collected it.

Until now company_linkedin_url_or only ever compared the URL against our stored slug. A URL built on the numeric ID was compared against slugs like deloitte, so it could never match — and it failed quietly: the request succeeded, returned zero results, and consumed no credits. It looked like we simply did not have the company.

That is fixed, in the same filter. All of these now find Deloitte, in both Company Search and Job Search:

{ "company_linkedin_url_or": ["https://www.linkedin.com/company/1038"] }
{ "company_linkedin_url_or": ["https://www.linkedin.com/company/deloitte"] }
{ "company_linkedin_url_or": ["1038"] }
{ "company_linkedin_url_or": ["deloitte"] }

If your calls already send numeric-ID URLs, they start matching on their own — there is nothing to change on your side, and no new filter to migrate to. A value that is entirely digits is matched against both the company's LinkedIn ID and its slug, so you never have to work out which of the two you are holding. Some companies genuinely have a numeric vanity slug, and this way both resolve.

In the app the same filter covers all of it: Linkedin URL, under Company in Company Search and Job Search, accepts a full URL, a bare slug or a numeric ID, one per line.

A note on coverage

The numeric LinkedIn ID is our least complete company identifier: we have one for about 14% of companies, against 26% with a LinkedIn slug and 29% with a domain. This change removes a failure that was total and silent, but it does not make every LinkedIn lookup resolve — an identifier we do not store still returns no results.

If you have the company's domain, company_domain_or remains the identifier that matches most often.