# Locations (/docs/api/locations)



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.

<EndpointList topic="locations" />

## Search locations [#search-locations]

<EndpointDemo id="locations-search" />

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 [#using-the-geo-ids]

```bash
# 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`](/docs/api/search) and
[`/v1/search/companies`](/docs/api/search) — pass the resolved
`geo_id` rather than free text for stable matching across cities.

## Notes [#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.