Locations
Resolve a city or region string to a canonical LinkedIn geo ID.
Most LinkedIn filters use opaque numeric geo IDs, not free-text city names. The locations endpoint resolves a search string to the canonical geo ID you need to pass into people, jobs, and company search.
The IDs returned are Microsoft Bing Geo identifiers — LinkedIn exposes them through their public typeahead. They're stable; cache them in your app and you almost never need to call this endpoint twice for the same query.
Search locations
/v1/locations/search1 creditType-ahead-style location resolution. Returns LinkedIn's Microsoft Bing Geo identifiers, the same IDs you pass into `/v1/jobs?geo_id=…` and other geo-filtered endpoints. Same query hits LinkedIn at most once per TTL globally; subsequent calls are served from the per-query cache.
The cache key is the normalised query string (lowercased, trimmed). A query that has been resolved within the TTL window (default 30 days) returns the bit-for-bit ordered list LinkedIn returned the first time — no row-count heuristic, no threshold logic, no hidden filtering.
?fresh=true skips the cache and forces a live LinkedIn typeahead
call. Costs the same.
Using the geo IDs
# 1. Resolve "Bay Area" once.
curl "https://api.linkfetch.io/v1/locations/search?q=san+francisco+bay+area" \
-H "Authorization: Bearer sk_live_..."
# → 90000084
# 2. Use it in a Jobs query.
curl "https://api.linkfetch.io/v1/jobs?q=staff+engineer&geo_id=90000084" \
-H "Authorization: Bearer sk_live_..."Same pattern for /v1/search/people and
/v1/search/companies — pass the resolved
geo_id rather than free text for stable matching across cities.
Notes
- 1 credit per call.
- Same query hits LinkedIn at most once per TTL globally, across all users — the per-query cache is shared.
- Empty result sets are also cached, so a typo doesn't keep hitting LinkedIn — but they're not charged.