Retrieve place details using the place ID

The place ID provides a reliable means of referencing information for a
particular place. These IDs are stable, meaning that once you've
identified the place ID for a place, you can reuse that value when you next
look up that place. If the place still exists, the API returns the same
place. Read about multiple IDs and scoping below.

A common way of using place IDs is to search for a place
(using the Places API
or the Places
library in the Maps JavaScript API, for example) then use the
returned place ID to retrieve place details. You can store the place ID and
use it to retrieve the same place details later. Read about
saving place IDs below.

Example using the Places library in the Maps JavaScript API

To use a place ID in your JavaScript app, you must first find the ID,
which is available in the PlaceResult returned by a
Place
Search, or by getPlace() in the
Place
Autocomplete service. Then you can use the place ID to look up
place
details.

Handle multiple place IDs and place ID scoping

Each place ID can refer to only one place, but a single place can have more
than one place ID.

A place may get a new ID in the following situations:

When a business moves to a new location.

When your application adds a place. If you add a place using the
Places API, you receive a place ID for the new
place immediately. This place ID is scoped for your application only. The
place then enters a moderation queue, awaiting approval for addition to the
Google Places database. If approved, the place receives a new place ID,
available to all applications and on Google Maps. See the documentation on
adding a place.

The following diagram shows a possible scenario where a place has more
than one place ID:

When a place has multiple IDs, it will have no impact on a
Places API request. However, it will affect the
response.

When you request a place by specifying a place ID, you can be confident that
you will always receive the most up-to-date details for that place, provided
the place still exists and the place ID is still active.

Note, however, that the place ID in the response may be
different from the one specified in your request, if the place has received
a new primary ID. You can safely continue to use the previous place ID to access
the place, but it's best practice to swap to the most recently-returned place
ID whenever possible.

If the place has multiple IDs scoped for your application, the
Places API will return the primary ID for the
place, and an array containing alternative IDs for that place. This array will
contain alternative IDs scoped for your application, but not the non-primary IDs
for that place. See the documentation on
place details
and place search.

Save place IDs for later use

Place IDs are exempt from the caching restrictions stated in
Section 3.2.4(a) of the Google Maps Platform Terms of Service.
You can therefore store place ID values for later use.

Note that you may receive a NOT_FOUND status code when you use
a saved place ID. Best practise is to refresh your stored
place IDs periodically, after 100 days for example. One strategy is to store
the original request that returned each place ID. If a place ID becomes
invalid, you can re-issue that request to get fresh results. These results may
or may not include the original place.

A place ID may become obsolete if a business closes or moves to a new
location.

Place IDs may change due to large-scale updates on the Google Maps database.
In such cases, a place may receive a new place ID, and the old ID returns a
NOT_FOUND response.

In particular, some types of place IDs may sometimes cause a
NOT_FOUND response, or the API may return a different place ID in
the response. These place ID types include:

Street addresses that do not exist in Google Maps as precise addresses,
but are inferred from a range of addresses.

Segments of a long route, where the request also specifies a city or
locality.