Place ID

A Place ID is Google's canonical identifier for a single physical business location, point of interest, or geographic feature. Format: ChIJ prefix + ~23 base64url-style characters (e.g. ChIJN1t_tDeuEmsRUsoyG83frY4).

Unlike a CID, which is Google's internal numeric identifier visible in Maps URLs, the Place ID is the public-facing string Google exposes through every documented API. The two IDs map one-to-one to the same business, but they aren't interchangeable as strings — you have to convert.

Place IDs show up in three places:

• Google APIs: the Places API, Geocoding API, and Google Business Profile API all return Place IDs and accept them as input.
• Third-party local-SEO APIs: nearly every local-data provider (DataForSEO, Outscraper, BrightLocal, Local SEO Data) accepts Place ID as the canonical input.
• Some Maps URLs: when a Maps share link includes ?place_id=ChIJ... (less common than the cid= format).

Most workflows that touch local-business data eventually need a Place ID. If you only have a CID, the conversion path is documented but requires a Google API call.

Three reliable methods:

• Google's Place ID Finder — Google's official web tool. Search for a business, click the result, copy the Place ID from the info panel.
• Google Maps share link — share a business from Maps, parse the URL for the place_id parameter (works for some businesses but not all).
• Reverse-resolve from a CID — if you have a Maps URL with a cid= parameter, you'll need the Places API to convert it to a Place ID. The CID resolver tool surfaces both formats when one is known.

In agentic workflows, the agent typically fetches the Place ID via Location Search API from a natural-language business description, then uses it for downstream calls.

Once you have a Place ID, every local-SEO data point flows from it. The Google Business Profile API takes a Place ID and returns NAP, hours, categories, photos, attributes. The Google Reviews API takes a Place ID and returns the full review history. The Local Pack API takes a Place ID to verify business identity in rank-tracking flows.

For agencies managing 50+ client locations, the canonical pattern is: resolve Place IDs once during onboarding, store them in your CRM, then every subsequent API call uses the stored Place ID. No re-lookups, no ambiguity.

Agents working with local-SEO data hit a recurring friction: users describe businesses in natural language ("the pizza place on Carmine St"), but APIs need Place IDs. The solution is a two-step prompt pattern: first resolve the natural-language description to a Place ID via geocoding or a location-resolution endpoint, then pass that Place ID into the data endpoint.

This pattern is now standard in MCP-based local-SEO workflows. The agent's first MCP call is almost always a resolution step; the second is the actual data query.