Authentication and Authorization

This page is only for customers with a previous Maps APIs for Work or Maps API for Business license. This page is not applicable to customers with the new Google Maps APIs Premium Plan, which became available in January 2016.

Client IDs

Authentication to the Maps JavaScript API for Google Maps APIs for Work customers requires a unique client ID in combination with URL registration.

Get a client ID

To access the special features of Google Maps APIs for Work, you must provide a client ID when accessing any of the API libraries or services. When registering for Google Maps APIs for Work, you will receive this client ID from Google Cloud Support Portal. All client IDs begin with a gme- prefix.

This client ID is not a key. It will only work from URLs which you authorize, so you don't need to worry about keeping it secret.

Specify a client ID when loading the API

Specify your client ID as the value of a client parameter when loading the Maps JavaScript API:

<script async defer src="https://maps.googleapis.com/maps/api/js?client=YOUR_CLIENT_ID &v=quarterly&callback=initMap"></script>

As shown in the above example, you must specify the release version (also referred to as the feature-stable version) or an earlier version, by appending a v=quarterly parameter. Applications that use the experimental version are not covered under the Google Maps APIs for Work SLA.

Register your authorized URLs

To prevent a third party from using your client ID on their own website, the use of your client ID is restricted to a list of URLs that you specifically authorize.

To see the URLs you have already authorized or to authorize additional URLs:

  1. Log in to the Google Cloud Support Portal.
  2. In the left-hand menu, click Maps: Manage Client ID.

You can add up to 100 URLs at a time. A Client ID may be associated with up to 3000 authorized URLs. If you expect your application to host Google Maps content from more than 3000 locations, you should switch to using API keys instead.

The following considerations apply regarding URLs that are authorized:

The domain name or IP address does not have to be publicly accessible.
For example, http://myintranet and http://192.168.1.1 are valid entries.
All subdomains of a specified domain are also authorized.
For example, if http://example.com is authorized, then http://www.example.com is also authorized. The reverse is not true: if http://www.example.com is authorized, http://example.com is not necessarily authorized.
All subpaths of an authorized path are also authorized.
For example, if http://example.com is authorized, then http://example.com/foo is also authorized. In addition, because subdomains of a specified domain are also authorized, http://sub.example.com/bar is authorized.
Paths are case sensitive.
For example, http://www.example.com/ThisPath/ is not the same as http://www.example.com/thispath/.
You may restrict valid URLs to those using certain ports.
For example, if http://example.com:8080/foo is specified, that doesn't authorize http://example.com.
HTTP and HTTPS protocols are considered different URLs.
For example, if https://example.com is authorized, http://example.com is not necessarily authorized. If you'd like to authorize both at once, you may add a domain without using a protocol: example.com/

All the rules above are applied to each authorization, so you should take care to plan your authorizations carefully. For example, because all subpaths of a specified path are authorized, and all subdomains, you may end up authorizing pages that you didn't intend to. For example:

http://example.com/ also authorizes http://sub.example.com/path.

For more information, see Troubleshooting Authorization for Google Maps APIs for Work Implementations.