Why is my Google Place ID undefined?

What should I check first in the raw response?

A missing ID field is a response-shape or field-mask problem when the raw response has a place object but does not contain the ID field your code reads. Google's Text Search (New) documentation says that the response is a JSON object with a places array and that there is no default list of returned fields. The request must include a field mask, such as places.id, through $fields, fields, or X-Goog-FieldMask. Omitting the mask returns an error.

Check the request and response in this order:

1. Save the raw JSON before your application mapper changes it.
2. For Text Search (New), confirm that the top level contains places and request places.id in the field mask. For Place Details (New), request and read id.
3. Treat name separately. In the New API, name contains the resource name places/PLACE_ID; the standalone Place ID is in id.
4. If the client variable is called place_id, map it from the New API id only after the endpoint has been identified. Do not expect the New API to return the legacy field name.

What if the search returned no place?

An empty places array is a no-result branch, not an obsolete-ID branch, because the response supplied no place from which to read an ID; if places is absent, check first that the raw response is not an API error. Google's Text Search (New) documentation defines places as the array of matching places and says that identical requests are not guaranteed to return a consistent list.

Save the request body with the response. Check the exact textQuery, the field mask, and the locationBias or locationRestriction. Rerun the search with a more specific business name and a known area. Do not call an ID obsolete until a previous response actually returned an ID and a later Place Details or refresh request rejects it.

What do INVALID_REQUEST and NOT_FOUND mean for a Place ID?

INVALID_REQUEST points to an invalid or modified ID, while NOT_FOUND points to an ID that has become obsolete. Google's Place IDs documentation says truncation or other modification can produce INVALID_REQUEST. A place can become obsolete after closure, relocation, or an update to Google's Maps database, and the old ID can then return NOT_FOUND.

Google says obsolete IDs may remain in autocomplete responses for a few days. Store the original request that produced each ID so you can refresh it. Google recommends refreshing stored Place IDs older than 12 months with a Place Details request that asks only for the ID field; the documentation says that refresh is at no charge. A reissued search used to replace an obsolete ID is billed at the appropriate SKU.

Which identifier am I actually holding?

A Place ID, a Business Profile location ID, and a store code can refer to the same business without being interchangeable identifiers. The Place ID glossary entry covers the Maps identifier. The neighboring Business Profile location ID answer covers the account-scoped API resource. Label the value by the field and endpoint that produced it:

Google's Business Profile API Location reference identifies locations/{locationId} as the Location resource name, storeCode as an external identifier unique within an account, and the Maps Place ID as an output-only field. Do not pass a locationId or store code to a Places endpoint that expects id or place_id.

How can I verify that a Place ID points to the right business?

Use a Maps URL with both a human-readable query and query_place_id, then compare the displayed place with the business you intended. Google's Maps URLs documentation requires query for a Search action. When query and query_place_id are both present, Maps uses the text query only if it cannot find the Place ID.

Use a URL-encoded version of this shape:

https://www.google.com/maps/search/?api=1&query=PLACE_NAME&query_place_id=PLACE_ID

Check the displayed name and address against the intended business. This verifies the ID-to-place link. It does not verify that a Google Account is authorized to manage the Business Profile.

Does resolving a Place ID prove ownership or ranking?

No. Resolving a Place ID identifies or links a place for a Maps or Places workflow; it does not prove Business Profile access or a ranking position. Google’s Business Profile editing guidance says that showing a business on Google services requires adding or claiming it and then verifying the Business Profile, while editing requires the linked Google Account.

Google's local-ranking guidance separately says local results are mainly based on relevance, distance, and popularity, and that a business cannot request or pay for a better local ranking. A resolved ID is not an ownership credential and does not establish a ranking position. For the broader Maps surface, use the Google Maps hub.