With the release of Places API (New), your first task is to decide which set of APIs to use. This is true if you are a new customer or an existing customer already using the APIs. Use this guide to understand the key differences between the two APIs.
List of APIs
The following table lists both sets of APIs. If you are an existing customer, use this table to determine the new API that replaces an API that you are currently using.
|Places API (New)
|Text Search (New)
|There is no new version of Find Place. Text Search (New) has replaced it.
|Nearby Search (New)
|All requests using the existing API that include a text query should use Text Search (New) because Nearby Search (New) does not support text input.
|Text Search (New)
|Place Details (New)
|Place Photo (New)
|Capabilities added to Preview version of Autocomplete (New)
If you are using an existing API and want to migrate to the new API, see the following migration guides for each API:
- Migrate to Nearby Search (New)
- Migrate to Text Search (New)
- Migrate to Place Details (New)
- Migrate to Place Photo (New)
- Migrate to Autocomplete (New)
Key features added to Places API (New)
This section covers key features added to Places API (New).
Implemented on the Google Cloud standard platform
Places API (New) is implemented on the service infrastructure on Google Cloud. This implementation brings with it a more secure and trusted platform with enhanced security options like OAuth. This standard API design brings a level of consistency across the APIs that improve the efficiency of development with Places API (New).
Places API (New) provides improved performance, making it worthwhile to replace apps that use the existing Places API.
Pricing is simplified with Places API (New) so that you only pay for the data you use. Simplified pricing is implemented using a field mask.
With Place Details (New), Nearby Search (New), and Text Search (New) you use the field mask to control the list of fields to return in the response. You are then only billed for the data requested. Using field masking is a good design practice to ensure that you don't request unnecessary data, which helps to avoid unnecessary processing time and billing charges.
Consistent response data for a place
With the existing APIs, the Place Details, Nearby Search, and Text Search APIs returned different response data for a place. Places API (New) standardizes the response so these APIs all return the same data for a place.
Expanded place types
The API response can now contain a place's primary type. Every place can have a single type value that is specified as the place's primary type, as listed in Table A.
In addition, the new API adds the place types shown in the table below. You can use these new types, and the existing types, in a search with Nearby Search (New) and Text Search (New). The new types are all included in Table A.
Dynamic place data
Places API (New) supports dynamic response data, such as the availability of an EV charging station or the latest fuel prices for a gas station. Use these response fields to create dynamic user experiences.
Which API do you choose?
Before you can start app development, you must choose your API:
If you are a new customer just getting started with Places API, then start with the new APIs.
If you are a new customer and there is not yet a replacement for an existing API, such as Place Autocomplete or Query Autocomplete, then you can use a combination of new and existing APIs.
If you are an existing customer, you can continue using the existing APIs. However, to take advantage of the performance improvements and the feature enhancements of the Places API (New), you can migrate to the new APIs.
For more information on migration, see Migration overview.